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Section 1 

INTRODUCTION 


Many factors in today's industrial nations are leading to a resurgence in railroad 
freight traffic; this means increased demands on railroads are appearing for timely 
and dependable service, as well as the capability to efficiently meet these changing 
demands. Together with these factors is the demand for increased productivity 
from the work force, rolling stock and facilities which must be achieved to meet 
the requirements for rail movement by cost-conscious customers. 

These pressures are, to varying extents, being felt by the other modes of freight 
transportation, and ultimately all modes are under heavy pressures to control costs, 
while providing dependable and efficient service. 

As transportation is a service provided over a possibly widespread geographic area, 
cost control, as well as service and operations control, must be effected at all 
major locations which can affect these vital factors. 

Realizing the current trends of industry, and following its experiences in rail, road, 
and other transportation information and control systems. Control Data has designed 
a system specifically tailored to the problems of the modern international railroad. 
This system, as with Control Data's Motor Freight CARRIER system (which is in 
use in a number of major trucking companies), is based on the most modern system 
design techniques and computer and communications technology. Today's data base 
management systems and programming techniques provide a significant advance over 
systems designed and implemented in the past. 

The principal locations which must provide the work needed to move freight by rail 
are the stations (yards) which collect cars from industry, deliver them to industry, 
and make up and break down trains. Work to be accomplished at these locations 
is critical and continuous, and the station master needs a full range of timely 
information available to him and his staff to assist in planning their operations and 
executing them. Hence, the principal yards or stations on a railroad are the focal 
points for a modern railroad information and control system. These locations will 
require the ability to report (or input) data describing basic events, and it must 
also be able to make inquiries into the system to get basic information on trains, 
cars, etc., as well as receive regular reports summarizing work inbound to the 
locations, etc. 
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The Rail-CARRIER system comprises, therefore, several basic parts: 

® Computer terminal devices located at major yards and other key 
operational offices (car distribution offices, district headquarters, 
train dispatch offices, etc.). 

a A communications network to link all the remote terminals to the 
central computer system. 

• A central computer system which retains records of all basic car, 
customer, yard, and train operations reported from the railroad 
as a whole, and which stores them in a real-time data base. Geared to the 
use of the railroad's operating department, the central system monitors 
major railroad movement events as they occur, as well as reporting 
vital operational information to all individuals and departments 
requiring timely information on any or all aspects of the railroad's 
operation and its equipment fleets. The system will also permit a 
message switching function between the remote locations. 

The system is designed to assist railroad management in monitoring and controlling 
its operations, in planning and/or controlling deviations from scheduled or assigned 
operational events, in generating and/or discriminating movement orders, and 
very importantly in providing all levels of management with performance reports 
and traffic analyses to ensure close measurement and control of the railroad as 
well as a continually evolving system for planning future operations. 

A short description of the basic reporting, monitoring, and control functions of 
the Rail-CARRIER system, as they pertain to the railroad, is given in the 
following paragraphs. 


• Train Operations 

The physical movement of all trains will be reported to and recorded by 
the system.. In addition, all trains being built will be monitored to ensure 
that train limits are not being violated and to give advance notice of limits 
being approached due to unusually heavy traffic (or other reasons) which 
may require train planning/dispatching offices to schedule an extra train. 
In addition, schedule changes, cancelled trains, etc., are all reported 
under this functional discipline. The controls inherent in the train area 
will permit close train traffic management, and the maintenance of an 
accurate data base describing current locations and status of all rolling 
stock. This rolling stock disposition knowledge is vital in planning, 
monitoring, and controlling the equipment fleets which is needed to be able 
to improve utilization and customer service. A full set of train-oriented 
operation reports and summaries is output by the system. 

Car (Wagon/Fleet Operations) 

All station-to-station car movements are reported via the consist 
discipline enforced in train operations; in addition, the consist 
discipline will cause all cars set off, or picked up by scheduled 
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local or through trains to be reported to the system. Cars come on-line 
and go off-line either through industrial switching or via interchange with 
other railroads. These movements are basically reported to the system 
so that changes in a car's status as it goes through its work cycle will then 
be recorded, reported, and measured according to the status it is in, etc. 
In addition, the system will require reports on cars leaving service for 
maintenance due to defects in running equipment, etc. Cars being stored 
in pools due to falling demand will also be reported, as will car(s) being 
reserved for a particular status. The object of the car operations 
discipline is to require a timely and accurate reporting of all status 
and location changes, so the system can monitor and assist in the plan¬ 
ning and control of any and all equipment fleets. Similar control is exer¬ 
cised on locomotives, guard vans (cabooses) and any special equipment 
fleet deemed to be in need of this type of control. 


A comprehensive series of reports describing such areas as: car utilization by 
customer, by type; car movement statistics; and off-line, on-line equipment status are 
available. 

In addition, the system will schedule loaded and empty car movements by route, 
block and scheduled train to whatever depth is required by a railroad. 


® Station (yard) Operations 

l 

Train and car event reporting will provide a full profile of all basic yard 
processing. The data captured by train and by car will permit a 
comprehensive set of reports for use by station management, and their 
management, describing such areas as: inbound workload (cars inbound 
on trains), missed connections (cars missing scheduled trains), car 
detention by yard, inbound freight by customer, scheduled outbound 
cars by station. These report types will prove a vital element in the 
assistance that the CARRIER system will provide station management — 
constant use of this information, and attention to trouble spots being 
reported by the system will permit yard personnel to enhance their 
operations consistently. 

• Maintenance Operations 

The maintenance function is designed to permit the maintenance department 
to schedule and control the (preventative) maintenance required on all 
rolling stock, and to do this interactively with operations so as to 
maintain orderly rolling stock service. In addition, equipment which 
becomes inoperable while being used will be reported into this function. 

All equipment to be maintained will be monitored and maintenance 
performance and standards-type reports will be generated. This 
comprehensive maintenance function should permit greatly improved 
maintenance functions and equipment maintenance cost control. 

® Customer Contracts 

Large volume and high-value customers may be permitted to enter into 
specific service contracts which may delineate such factors as: the actual 
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flow of cars to and from a customer, the trains to be used, etc. The 
system will maintain updated records on all customer contracts. These 
contracts may call for such factors as Specific train movements. 

Any deviations will be reported by the system; in addition, specific 
blocking and scheduling contracts will cause the relevant consists to be 
updated accordingly. 

• Traffic Analysis 

The system, in gathering and keeping records of all basic freight 
movements, whether on a train, to a customer loaded, etc. , will 
have the ability to perform practically any analysis of its traffic 
flow which it may require. Specifically at this time, the system 
will provide such reports as: 

— Weekly reports on specific train operations 
— Reports on expected train traffic 

— Tonnage carried for major customers 

— Comparative traffic loading 

— Monthly and yearly summaries of inbound and outbound 
freight by station. 

The Rail-CARRIER type of on-line system, its reporting demands and potential 
management controls, as well as the possibilities it opens to the railroad planner, 
must be approached carefully. The system will come to be involved in almost 
all major departments in a railroad and this represents a major change in the way 
a railroad has historically conducted its business. To be assured that the system 
will be used to its full potential and that its introduction will not cause disruption 
to normal freight operation activities, system implementation must be carefully 
studied. Control Data is keenly aware of the need for careful implementation plan¬ 
ning tailored for each specific railroad; a section of this report discusses a possible 
and feasible implementation plan which can be used as a general guidelines. The 
actual location, function, and time schedule to be observed in a railroad must be 
planned by the railroad in question. 

This system has been planned with the requirements and operating practices of the 
international railroad in mind. The planning has been done in the light of experience 
gained by other railroads over the past decade or more. With careful consideration 
of functions to be implemented, changed procedures required to more adequately 
suit a particular railroad's practices, and the definition of a well reasoned imple¬ 
mentation plan, the benefits accruing to a railroad installing a Rail-CARRIER 
system can be very substantial. 
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Section 2 

SYSTEM DESCRIPTION 


INFORMATION FLOW 

CAR AND TRAIN MOVEMENT INFORMATION FLOW 

The on-line system described in this document is concerned with keeping a full set of 
contemporaneous data describing the principal movement, repair, and status change 
events occurring on a railroad. This basic design philosophy requires that a set of 
principal events be determined and reported — where the set of principal events re¬ 
presents those major events which, if not accomplished in a timely and accurate 
fashion, will cause operational and service delays, etc. More minor events which 
may be necessary to accomplish major events are not reported in the system until a 
later phase, or may not be recommended for reporting (at least to a central computer 
facility). Examples of major events are train consist build, train dispatch, train 
arrival, and rolling stock maintenance; minor events currently include generating 
industrial switch orders for yard switchers, flat yard switch lists, locomotive fueling 
orders, etc. 

This section describes how the computer system reporting requirements and the 
accomplishment of related major operational events fit together, and how the com¬ 
puter system will basically assist operations management in the planning and execu¬ 
tion of their responsibilities. This basic description should be augmented by a close 
study of the reports being generated, summarizing car, train, traffic, and yard work 
accomplishments for use on station, district (regional), and head office levels. This 
information is provided in Section 3. A similar description of a basic car distribution 
cycle from an operations and computer viewpoint is provided. 

The basic information and event flow described in this section is represented in 
Figure 2-1. The following describes events represented in the diagram, commencing 
at the top of the diagram. 

The upper left-hand event represents a car(s) being received in interchange; these 
car(s) are reported to the system to update the files describing home cars returning 
on-line or foreign cars being received on-line. These cars are inspected via the BAD 
event (this is basically for bad order inspection, but it should be expanded to include 
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other servicing events such as customs clearance; cleaning; ice or heat servicing; 
livestock service such as water, rest, and feed; airing; etc. Cars requiring main¬ 
tenance (and/or service) are reported bad ordered (and the data base updated accord¬ 
ingly), and are either directed to the appropriate facilities (maintenance shop, etc. ), 
or move orders are generated for dispatching bad ordered cars to a repair facility. 
Cars being received in interchange that do not require repair or servicing following 
inspection join the event stream of other cars coming on-line from industry. 

Cars are received (empty or loaded) from industry as shown in the right uppermost 
event box. These are similarly inspected for bad order condition, and a service 
determination is made. Cars requiring maintenance follow the BAD order event 
path described above. The cars not requiring such attention are ready for assignment 
and/or movement. Cars are either empty or loaded. 

Empty cars are available for scheduled maintenance, and are dispatched to a desig¬ 
nated maintenance shop in accordance with car maintenance move orders as described 
in Section 3; the data base is updated to reflect maintenance events. The nonmain¬ 
tenance ordered empty car is then scrutinized to ascertain if it is assigned (by type 
assignment or number) to move to fill an empty car demand at some other location, 
or it may be held, or ordered held, for later assignment from its current yard. 
Nonassigned empty cars may be ordered to move (as a type or by number) to a pool 
storage location. If a car is ordered to move, the routing, blocking, and scheduling 
of the empty car must be accomplished. (This is the same process as for loaded 
cars and is explained below.) Essentially, the first move of the car's route is deter¬ 
mined by the yard master, or his staff. The system assigns any later blocked 
movements and scheduled trains for the car to reach its final destination. Once 
blocked and assigned to an initial train, the car is built into the train, and is reported 
via a consist build/consist maintain message. 

If the car coming on-line is loaded and not bad ordered, it follows a different 
logical path. The first question to be answered is whether the car was contracted 
to travel on a specific train from this station (this type of movement contract for cer¬ 
tain customers/movements is prevalent in certain railroads). If the car was con¬ 
tracted to travel on a specific train, it must be determined if the car can be put on 
the train or if it has missed its connection. If the connection has been missed or can¬ 
not be made, the connection is reported missed and the car event file updated. Con¬ 
tracted car movements flow directly to the contracted train consist build/maintain event; 
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missed connections for contracted cars require car rescheduling and flow to the 
bio eking/scheduling event; uncontracted cars have their first move assigned 
following the routing/blocking scheduling orders of the railroad. The system, which 
has a record of the railroad's routing/blocking/scheduling rules, determines the 
desired future moves of the car and updates the future consists being built accordingly. 
The blocking/scheduling function is tailored to conform with each individual railroad's 
philosophy and operating rules and procedures. If all routing/blocking/scheduling is 
to be done manually, this requirement can be easily encompassed by the system. 

It is recommended that the initial train movement of a car be determined manually 
according to a railroad's routing/blocking/scheduling rules and that later moves, 
etc., be determined by the system according to these same rules. This obviates 
the need for an extra data entry describing the car (when it is first received on-line 
in a yard) which would be necessary if the system had to do all train assignment. 

This is a practical arrangement in the initial phases of operation for a system of 
this type. As mentioned in the yard subsection of Section 4, earlier car data input 
may be desired, thus allowing complete scheduling by the system. Railroads re¬ 
quiring way-bill data entry before movement can commence, may also have a blocking 
pattern and train schedules completely determined by the system. 

A determination will be made to see if assigned empty cars have missed or will miss 
their scheduled trains; similarly, if loaded cars not under contract, but which have 
a train move scheduled, will make the train build cycle in time. If missed connec¬ 
tions are evident, these facts are reported and the Car Event file is updated. Also, 
missed connection reports are generated for use by appropriate management to re¬ 
view for frequency of occurrence, etc. 

The next function shown is the consist build /maintain event where all information 
describing cars moving on trains is entered into the system, and the train consist 
is completed. To assist the yard master in planning trains, the system prints out, 
on request, either inbound train consists or expected future consists, or both. The 
system examines a reported consist (or consist update) for car feasibility and move 
feasibility, and ensures that height, width, length, and load restrictions for a particu¬ 
lar train are not being abrogated. This last editing may result in cars being bumped, 
rescheduled, and inputted to a future consist. 
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This consist is sent to required down-line stations. The train is dispatched, and the 
dispatching is reported to the system, as well as to the next reporting arrival station 
on its schedule. The actual arrival time of a train at an inbound station is reported 
in a timely fashion. These reported events update the Train Event file; summaries 
are made of late and early train schedule deviations for traffic/dispatch management. 
The arrive train event may be followed by the removal of cars from the train which 
were observed to have defective equipment; this type of car is treated in the same 
manner as bad ordered cars reported earlier. 

If the train has arrived at a border/interchange yard, cars being set off at such a 
station for interchange must be reported as going off-line via a car interchange de¬ 
parture message. This information is used to update the On-line/Off-line file, and 
appropriate and timely reports summarizing these events are generated by the sys¬ 
tem for use by responsible management. 

The train's consist is maintained (if it is ongoing) to reflect errors in the original 
consist which were detected enroute or at the arrival yard, and to reflect cars set 
off or picked up (spotted or pulled) in industrial movements between yards (a typical 
local train activity). In addition, consist changes representing cuts or blocks of 
cars being switched onto or off a train will require consist maintenance message 
activity, hence, the flow loops back through the major train consist and movement 
activities. Prior to this, if train delays occurred, some cars to be switched may 
have missed their connections; this determination, together with rescheduling, is 
necessary. 


SYSTEM CAPTURE OF CHANGED DATA 

The system is concerned with assisting railroad operations management in the plan¬ 
ning, monitoring, and controling of various responsibility areas. The monitoring 
function is concerned with tracking known equipment being processed by planned 
events. This monitoring requires the system to have, and maintain, a data base 
describing a variety of events, etc. The system data requirements are; 

@ The Train Schedule must be maintained in an accurate fashion. All cancelled 
trains, and special trains, must be reported to the system, as are all train 
schedule deviations. When the description of a train's schedule changes to 
reflect such factors as changed powering levels (which affects a train's 
tonnage capacity, etc.), changed station stops, changed speeds, etc., this 
information must also be input to the system. 
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The car fleet must be completely described (as with the locomotive, caboose 
[guard van] fleets) in the data base. This description includes unit number 
(initial and number for foreign cars temporarily on-line), length, empty 
weight, braking coefficient, car type, loaded capacity, beginning service 
date, and projected maintenance data. Other information describing main¬ 
tenance status (miles traveled, weight carried, etc. ) may be captured at a 
later date but it is not required initially. Also, as transportation contracts 
change, cars are reassigned onto or off a particular contract. This data is 
also entered. If cars are withdrawn from service for storage in an empty car 
pool, these assignments are entered into the system, and the appropriate 
car file updated. As new cars are added to the fleet, old cars retired, or 
existing cars rebuilt or modified, the data base must be updated accordingly. 
The locomotive fleet must be completely described: number, beginning 
service date, power rating, etc.; the data must also be kept current. 


CAR DISTRIBUTION! INFORMATION FLOW 

An initial car distribution function which can be automated is described in the follow¬ 
ing subsection. More sophisticated techniques to assist car dispatch management in 
scheduling and control of empty car fleets will not be described here. Basically, 
the subsection will be concerned with the regular reporting cycle for empty car supply 
and demand data, and the issuing of empty car movement orders back to responsible 
district and yard management. Again, this subsection describes both the operational 
events and the related flow of data to and from the on-line system. The following 
paragraphs describe the sequence of events shown in Figure 2-2. 

The distribution function is concerned with assigning cars to meet customers' orders, 
returning foreign cars, assigning foreign cars to customers' orders, cross-hauling 
cars between districts to balance overages and shortages, moving surplus cars to 
pool storage locations, and returning cars from storage locations. In addition, up¬ 
grading cars to overcome shortages of cars of a specified type and classification can 
be scheduled and accomplished by this cycle. 

The car distribution function is essentially a cyclical chain of events which is repeated 
each day in a set fashion, and probably following a rather similar time schedule. The 
possibility of nonscheduled events, and events where planned car movements did not 
occur, are included in the following paragraphs. This basic car distribution cycle 
and its computer involvement can possibly be replicated on many railroads. Changes 
in this logic can, in most cases, be encompassed without major difficulty. 
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The initial event in the cycle is the reporting to the system of all empty car demand 
and supply data by each station. Stations not automated can either report their data 
via telephone to an automated station, or can be canvassed by an automated station 
and included in its daily data. When the demand data is received for a station, the 
system assigns a reference number to the demand. All car movements needed to 
fill this demand carry this reference number, as will all reporting to the demand 
station describing inbound car movements to fill the demand. The supply demand 
data/station is used to update the Demand/Supply file in the on-line system. All home 
car demand/supply data is reported to the responsible district. The system monitors 
the stations reporting, and nonreporting stations are sent reminder messages. . 

All foreign car supply/demand data is sent directly to the head office car dispatchers 
who manually determine foreign car move orders. These move orders are input to 
the system to generate and disseminate foreign car move orders directly to stations, 
and to update the foreign car records in the data base. Stations not able to comply 
with foreign car move orders report this fact, and new (adjustment) foreign 
car move orders are generated and sent directly to stations. The data base is also 
updated. 

All home car empty supply/demand data is summarized by type and by district. This 
information is sent to head office car distribution personnel and dispatchers. These 
dispatchers determine the interdistrict balance movements needed by car type. 

These required movements are sent to each district, and the data base is updated. 
Districts unable to comply with these orders will report this inability, which is re¬ 
corded in the data base. If necessary, new (adjustment) move orders will be sent 
and recorded. 

Upon receipt of their home car move orders, the districts manually determine how 
they will comply with their interdistrict move orders and their intradistrict demands. 
This will be in the form of station move orders which are generated and disseminated 
following district input to the on-line system. Stations unable to comply will report 
this situation, the data base will again be updated, new move orders will possibly 
be cut, etc. 
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GENERAL DESCRIPTION 

The general Rail-CARRIER system consists of four basic parts: 

® A number of terminals distributed around the railroad 

@ A data communications network 

® A central computer system 

® A data base system 

Refer to Figure 2-3. 

TERMINALS: 

A number of terminals of different types can be used for the operation of the Rail- 
CARRIER system. Low-speed terminals are used at the railroad stations and some 
of the offices of the railroad. These terminals have a keyboard and a low-speed 
printer, the speed of which may vary between 10 and 30 characters per second. 

At Headquarters and district offices, faster terminals may be located. These 
terminals should have a card reader and a line printer. Printing speed is about 300- 
600 lines per minute. These terminals are used for producing larger reports and 
multiple copies of a report. 

Other types of terminals may also be used, if necessary. 

COMMUNICATION NETWORK 

Messages between terminals, or between terminals and the central computer system, 
are routed through a general data communication network. The routing of messages 
through the network is controlled by one or more 2550 data communication controllers 

Control Data's 2550 data communication controllers are a family of 16-bit mini¬ 
computers especially designed to be used in data communication networks. The 
computers are modular and may handle from 2 to 256 communication lines of 
different speed and types. A communication line may connect either to a terminal 
or another 2550; there is no practical limitation on the number of terminals that 
may be connected to the network. 
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At least one of the 2550s has a direct connection to the central computer system. 

Data is routed through the network by means of a packet switching technique. This 
technique, together with the very dependable and flexible data communication con¬ 
trollers, ensures a very reliable network. The network maybe configured so that if one 
or more of the 2550s becomes inoperable, the network will still be operational, but 
with reduced capacity. 

CENTRAL COMPUTER SYSTEM 

The central computer system is built around a CDC CYBER 170-series computer and 
the Network Operating System (NOS). 

The CDC CYBER 170 series, which is based on the most advanced computer design 
and technology available today, offers a comparitive capacity range of 1 to 10. The 
smallest model in this series, the Model 172, which may be incrementally upgraded 
to the larger models, is used for running the Rail-CARRIER system for a small- or 
medium-sized railroad. 

The NOS operating system is a general-purpose operating system especially designed 
for communicating with a large data communications network. NOS simultaneously 
runs transaction processing, batch jobs, and any type of time-sharing on the entire 
CDC CYBER 170-series computers. 

Transaction processing is handled by TRANEX, an NOS subsystem. NOS routes all 
data coming from a transaction terminal to TRANEX, which analyzes the trans¬ 
action, and initiates the jobs necessary to process the transaction. TRANEX pro¬ 
cesses more than one transaction simultaneously. Data from TRANEX is trans¬ 
mitted to the data communications network through NOS. The actual routing of the 
data is controlled by the network. 

DATA BASE SYSTEM 

The data base system used for implementing the Rail-CARRIER system on the CDC 
CYBER 170-series is TOTAL. This system runs on most of the large computer 
systems and is the most widely used data base system available today. 
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The system was chosen for implementation of the Rail-CARREER because of its 
ability to handle complex structured data and because of its efficiency and low 
system overhead. 

TRANSACTION PHILOSOPHY 

The transactions to the Rail-CARREER system are normally input through a trans¬ 
action terminal. However, the system also accepts transactions input on punched 
cards. The cards may be read through a card reader located at a central site or 
through the card readers of some of the terminals. 

Each transaction is assigned a priority number; the manner in which the transaction 
is handled depends on this priority. A transaction with very high priority is handled 
as soon as possible after it has reached the central computer; typical response time 
for these transactions is 2 to 10 seconds. 

The transactions with the lowest priority are handled only when the high priority 
load on the system permits. With these transactions, the elapsed time between 
transaction input and output will range from minutes to hours. 

The output resulting from the processing of a transaction is routed in different ways, 
depending on the origin and priority of the transaction. 

The priorities of the transactions are divided into four groups. 

GROUP 1 

Transactions in this group require fast response time and produce relatively little 
output. The output is always sent back to the sending terminals and to other appropri¬ 
ate terminals. 

GROUP 2 

The transactions in this group demand responses within minutes. These transactions 
may produce more output than the transactions in group one. This system limits 
the number of lines to be sent to a low-speed terminal. The full output may be sent 
to any high- or medium-speed printer. 
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GROUP 3 


Transactions in this group require response times ranging from minutes to hours. 
Output resulting from these transactions will never be routed to a low-speed terminal; 
however, it may be routed to a terminal with a medium-speed printer. 

GROUP 4 ; 

Transactions that demand response times ranging from several hours to one day 
are located in this group. These transactions may produce voluminous reports and, 
to process the transaction, removable disk packs may be needed. The output is 
always routed to a high-speed line printer either at the central site or at a high-speed 
terminal connected to the communications network. 

The transactions in the same group may have different internal priorities. This 
priority affects only the response times for the transactions. The computer 
operators at the central site may change the internal priority of transactions within 
the same group. 

DATA BASE 

The data base needed for the Rail-CARRIER System has a rather complex network 
structure. Due to this complexity and the requirement for concurrent use of the 
data, the TOTAL data manager has been chosen. TOTAL has a low central memory 
requirement and utilizes mass storage effectively, which is necessary in a trans¬ 
action-oriented environment. 

A data base using TOTAL is made up of two types of files: 

9 Single entry files 

Each record has a unique key and may be retrieved by this key. 

@ Variable entry files 

The records are linked to one or more record in a single entry file. 
Records linked to the same single entry record are also linked together. 
Multiple record formats may be stored in the same file. 

By means of these two types of files, complex data bases may be created 
and maintained. 
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Notations used when describing TOTAL data bases are: 


RECORD TYPE 


Single entry file, access through 
record key. 


Variable entry file, access through 
a record in a single entry file. 



Occurrence of one or more single 
entry records. 


'One to many' relation between a 
single entry record and variable 
entry records. 


Occurrence of one or more variable 
entry records. Each must be owned 
by at least one single entry record. 
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Files used in the Rail-CARRIER data base are as follows: 


• Route 

The trains on the railroad network travel predefined routes; each of 
these routes is described in this file. Data stored is route identifier, 
capacity limitations of the route, etc. 

® Rost (Route/Station) 

This file is used for linking all the stations along a route and then giving 
all the routes passing a station. 

® TRRO (Train/Route) 

This file is used for linking trains and corresponding routes. 

® Train No. 

A record for each scheduled train on the railroad network is kept in this 
file. Data stored is train identification, type of train, etc. The file is 
updated when new or extra trains are scheduled, or trains are cancelled 
for a period of time. 

• Sched/Descr. 

A record for each of the scheduled stops of the train on the railroad 
network is stored in this file. Data stored in each record is station, 
arrival and dispatch time, planned capacity and locomotives for each 
leg of the route, days when a train does not stop at the station, etc. 

Data about extra trains is also stored in this file. 

• Station 

Each station used by the railroad has an entry in this file. Data stored 
is the identification of the station, type of station, district and area code, 
pointers to sidings, tracks, etc. 

• Station Event 

This file contains an entry for all cars which should be picked up at a 
station by one of a group of specified trains. A record is stored in this 
file when a loaded car is received from a customer siding, when a car 
is set off one train to be picked up by a connecting train, etc. Data 
stored is car identification, destination, identification of the train 
which is to pick up the car, etc. When the car leaves the station, the 
corresponding record is deleted. 

® Car No. 

All rolling stock (including locomotives, cabooses, etc. ) used by the 
railroad has a record in this file. Data stored is identification, mileage, 
owner, time last maintained, etc. 
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Car 


A detailed description of all of the rolling stock used by the railroad. 

Data stored in this file is owner, type, weight, length, maximum 
speed, maximum load, braking weight, load carried, detailed description 
of the equipment of the car, etc. For the locomotives, the file also 
contains data about load hauled, tractive power, type, etc. The records 
in this data base are linked to records in other files. For example, 
when a car is located at a station, but not within a train, it is linked to 
the Station file.' When a car is dispatched from a station on a train,' it' 
is delinked from the Station file, and linked to the corresponding record 
in the Train file. This file is updated each time an event occurs to a 
car. 

• Car Events t 

Each time a record in the car file is updated, a record reflecting the 
changes is stored in this file. When a car is dispatched from a station, 
planned train connection switching is also stored in this file, and the 
records are limited to the corresponding Train and Station records. 

As the actual events take place, the records are updated to show what 
actually took place. Most of the reports on car utilization are produced 
from this file. 

The file contains historical data about all car events on the user's 
railroad, and the size of the file may become very large. To prevent 
this file from filling up all available mass storage, the records reflecting 
events that took place more than two weeks ago must be copied to tape 
and deleted from the data base. 

© Car Type 

This file contains an entry for each type of rolling stock utilized by the 
railroad. All of the cars, etc., of the same type are grouped through 
records in this file. Data stored is equipment type, and a brief descrip¬ 
tion of the type. 

• Group Link and Group 

These two files are used for grouping cars of the same type together. By 
entering the data base through these files it will, for example, be easy to 
find information stored in the Car file near all locomotives. 

© T rain 

Each time a train is built, a record is stored in this file. The record is 
deleted as the train reaches the destination station. Data stored is train 
identification and type of train. Each record is linked to the Car records 
of the equipment standing in the train in the same sequence as they are 
present in the train. The link is updated as the consist is changed at 
intermediate stations to reflect the actual consist of the train. 
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Train Events 


For each planned train event, a record is stored in this file, and the 
records are linked to the station where the event is planned to happen. 
Examples of train events are arrival or dispatch of a train from a 
station. Data about unplanned train events is also stored in this file. 

As the event actually happens, the records are updated to reflect how the 
event took place. Data stored is: planned and actual arrival and dis¬ 
patch time at a station, train capacity, weight, length, locomotives used, 
braking weight, etc. 

Records concerning events that took place more than two weeks ago are 
copied to tape and deleted from the data base. 

The Train Event file is used for producing reports on train utilization, 
deviation from schedules, total weight of freight moved in a given time 
interval, etc. 

• On/Off Line 

When a home car goes off-line or a foreign car comes on-line, a record 
is stored in this file. This file is used for keeping track of foreign cars 
and also for producing statistics about the time home cars are off-line, 
foreign cars on-line, etc. The file is updated to reflect home cars re¬ 
turning or foreign cars going off-line. 

® Status 

A car might be assigned one or more status, such as: bad ordered 
(defective), loaded, empty, being repaired, etc. All the cars with the 
same status are linked through records in this file. 

• Siding 

The sidings within the responsibility area of each station have a record 
in this file. The record is linked to the responsible station. Data kept 
in the file is the track identification and track description, etc. 

• Siding Link 

These two files establish correspondence between sidings, stations, and 
customers using the sidings. The file is updated as the number of 
customers varies. 

@ Customer 

Records for each customer using the railroad are kept in this file. Data 
stored is: customer name, address, telephone number, etc. The re¬ 
cords also contain pointers to cars owned or leased by the customer. 
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Contract No. 


When a contract for transporting one or more cars is agreed upon by the 
customer and the railroad company, a record is stored in this file. Data 
stored in the file is: contract number, type of contract, and a pointer(s) 
to the car(s) involved in the contract. 

• Contract 

More detailed description of the contracts is stored in this file. The 
records contain pointers to customer and contract number. 

® Contracted Train 

When customers contract for their loaded cars to be picked up by a 
specific train, a record is stored in this file. Each time a loaded car is 
released to the railroad by the customer, this file is consulted to find the 
contracted train that is to move the car. 

® Demand/Supply 

This file is used for the car distribution system. A record for each 
station and district is always present in this file. When a station has 
reported its daily car supply/demand data, it is stored in this file. 

After all stations have reported, the total demand/supply is summed by 
region, and stored in the corresponding region records. 

Data stored is station or district identification, demand and supply for 
each type of home car, and demand and supply of foreign cars. 

Data about supply and demand is erased by midnight. 

• Region 

One record for each railroad region (district) is stored in this file. Data 
stored is: identification of region, pointers to the stations in each region, 
and pointers to demand and supply of a region. 

• Reporting Status 

Records in this file link all stations that have reported car supply/demand. 
After midnight, the link is changed to indicate that no stations have re¬ 
ported this day. As the stations start reporting, the links are changed 
accordingly. 

• Ref. No. 

Each report of car supply or demand is assigned a reference number and 
this file establishes correspondence between this number and the supply/ 
demand data stored in the Demand/Supply file. 
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® Foreign Car 

The reported data of demand and supply of foreign cars at the stations 
are chained through this file. This file also contains pointers to_ move 
orders given by the head office to move foreign cars. The data is 
erased by midnight. 

® Move Orders 

When the head office has finished the manual distribution of groups of 
home cars, move orders are issued to the regional offices. Data 
describing the move orders is stored in this file. Data describing 
orders to move foreign cars (given directly to the stations) is also 
stored in this file. Data in this file is erased by midnight. 

Figure 2-4 illustrates the database file relationships; Table 2-1 provides a summary 
of these files. 

SYSTEM RESPONSES 

Each input message is acknowledged to inform the terminal operator that the 
computer has received the transaction. 

One of the following three responses is received. 

1. An error message. 

2. An inquiry reply. 

3. A date and time stamp. 

All messages are edited for format and content validity (see below). If an 

error is detected, the system responds with an error message. Each error message 

has a reference number assigned by the computer. 

If an operator is using an interactive transaction, responses are in the form of 
computer replies. However, if an input-only message is acceptable to the system, 
only a date and time stamp are returned. 


EDITS 

Edits are performed on all entries where possible. Message codes and subcodes are 
validated on all messages. Train and unit numbers are checked to ensure that these 
numbers are known to the system, and movements and status changes are checked 
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Figure 2-4. Data Base File Relationships 


2-20 
























TABLE 2-1. DATA ELEMENT RELATIONSHIPS 


File 

Contents 

Type 

Cod 

Car 

Car No. 

1:1 


Car 

Car Type 

1 :N 


Group Link 

Car Type 

1:1 


Group Link 

Group 

1 :N 


Car Events 

Car No. 

1:N 


Car 

Status 

1 :N 


Car 

On/Off Line 

1 :N 


Car 

Station 

1 :N ' 


Car Events 

Station 

1 :N 


Car 

Train 

1 :N 


Car Events 

Train 

1 :N 


Train Events 

Train 

1 :N 


Train Events 

Station 

1 :N 


Siding Link 

Station 

1 :N 


Siding 

Siding Link 

1:1 


Car 

Customer 

1 :N 


Contract 

Customer 

1 :N 


Car 

Contract No. 

1 :N 


Contract 

Contract No. 

1: 1 


Contracted Train 

Contract No. 

1 :N 


Demand — Supply 

Station 

1 :N 


Demand — Supply 

Region 

1 :N 


Demand Supply 

Ref. No. 

1:1 


Demand Supply 

Foreign Car 

1:N 


Move Order 

Foreign Car 

1:1 


Move Order 

Station 

1 :N 


Station Events 

Station 

1 :N 


Move Order 

Region 

1 :N 


Demand / Supply 

Reporting Status 

1 :N 


ROST 

Station 

1 :N 


ROST 

Route 

1 :N 

Cl 

ROST 

Route 

1 :N 

C2 

TRRO 

Train No. 

1 :N 


TRRO 

Route 

1:N 


Schedule/Descr. 

Station 

1 :N 


Schedule / Des cr. 

Train No. 

1 :N 



Function 

Links car (unit) number to car (unit) data 
Links car (unit) of same type 

Establish connection between car (unit) type and 
car (unit) group 

Links cars (units) within same group 
Planned and actual events for a car (unit) 

Gives status associated with a car (unit) 

Chains cars going off-line or coming on-line 
Chains all cars located at a station 
Links actual and planned car events to station 
Consist information 

Links events planned for each car in train 

Events planned and actually occurred for a train 

Train events related to station 

Links siding to customer and stations 

Establish correspondence: siding — station 

Cars owned or leased by customer 

Contract associated with a customer 

Cars involved in a contract 

Contract details 

Trains involved in a contract 

Demand and supply of cars at a station 

Chains the car demands and supply of districts 

Associate a reference number with demand and 
supply 

Chains all foreign cars 

Order to move a foreign car 

Links move orders to a station 

Links station events to stations 

Links move orders to district 

Links all stations reported demand/supply 

Links station to routes 

Links routes to stations 

Gives possible routes to reach another route 

Links trains to routes 

Links routes to trains 

Links station to scheduled trains 

Gives the schedules for each leg of a train 
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against last movement and status. In the cases where absolute values are not 
known, such as dates, times, and weights, the figures are checked for reasona¬ 
bility. If customer or contract numbers or codes are used, each entry is checked 
to ensure that the number or code has been entered properly. Additional edits 
performed are briefly outlined in the various message descriptions. 

It is necessary to identify the reporting station only when the message is sent from 
a terminal not located at that station. The system assumes that the terminal sending 
the message is at the station at which the event occurred. Should a station's computer 
terminal be inoperable, another station may report for it by identifying the station 
the report is for. 
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Section 3 


TRANSACTIONS 

This section contains the major discussion of the equipment control system from 
the user's point of view. The section, which is divided by major operations-oriented 
functional entities (train, car, yard, etc.), describes all real-time messages and 
all responses. This real-time orientation is at the heart of any transportation 
equipment control system. The data base must be updated in a timely fashion, and 
answers to time-critical information needs must also be received in a timely 
manner. 

The system, in capturing a continuous description of all major real-time operational 
events, is able to compile an impressively detailed and complete history of the 
railraod's activity stream. This enables railroad planning departments and manage¬ 
ment to determine and review historical trends, and to plan future operations and 
business activities accordingly. The major non real-time report types offered by 
the system are described in this section. Again, these reports are discussed in 
the generic operational area to which they pertain. No rigorous discussion has been • 
attempted to strictly delineate which railroad department should use which message/ 
function/report as this will vary between railroads, as organizational structures and 
responsibilities vary between one railroad and another. However, the types of 
information available, and necessary, are discussed and general comments made 
regarding the utility and basic function to be served by different reports, etc. 

The major areas by which the system is analyzed in this section are: 

1. Train Transactions 

2. Car Transactions 

3. Station /Yard Transactions 

4. Maintenance Transactions 

5. Contract Transactions 

6. Data Base Update Transactions 

7. Traffic and Special Messages 
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8 . 


Locomotive Transactions 


9. Administrative Message Switching 

The subject of Car Distribution is treated in detail in Section 4. 

Each Transaction subsection is preceded by an alphabetically ordered list of 
the transactions described in the section. 

The actual order in which the transactions are presented within each section is 
intended to reflect the basic transaction implementation sequence. 

TRAIN TRANSACTIONS 

An alphabetical listing of train transactions and descriptions of these transactions 
are as follows: 


Transaction 

Function 

Page 

TAR 

Arrive train 

3-7 

TCB 

Consist build 

3-3 

TCL 

Train cancel 

3-9 

TCM 

Consist maintenance 

3-4 

TCR 

Request consist 

3-8 

TCS 

Request cancelled train summary 

3-11 

TDC 

Train description change. 

3-9 

TDL 

Train delay 

3-10 

TDR 

Request late train dispatch summary 

3-10 

TDS 

Dispatch train. 

3-7 

TSD 

Request schedule deviation summary 

3-12 

TSS 

Request switching summary by train 

3-11 

TUG 

Request summary of train capacity utilization 
by leg 

3-11 

TUL 

Request weekly summary of train capacity 
utilization by lane 

3-11 
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Transaction 


Function 


Page 

3-10 


TXS Request extra train summary 

TXT Extra train. 3-9 

TCB — Consist Build 

Prior to the departure of a train, a final consist must be prepared showing the 
equipment by actual standing order, on the outbound train. Entered are train 
number, departure date, and train description information. The following are then 
repeated for each car: 

e Car number 

• Status 

9 Commodity 

• Final destination (siding, if applicable) 

« Intermediate transfer station 

• Loaded weight 

• Consignee identification 

• Contract number (if applicable) 

• Remarks, etc. 

Empty cars will have car identification, intermediate transfer station and desti¬ 
nation. Additional edits are performed to check gross weight, braking weight, and 
length, against the power capabilities, and route restrictions which may exist for a 
train. 

If it should become evident (based on cars entered into the consist) that the limits of 
the scheduled train's capacity (total tons, length) are being approached, a message 
so indicating is generated and transmitted to the yard terminal responsible for the 
train. Also, at the initialization of the consist build planning cycle in the yard 
office, the to-date consist expected can be requested from the central site. This 
to-date consist expected represents all cars whose blocking and scheduling has 
caused them to be scheduled for a particular train. 
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If desired, a car movement priority scheme could be implemented. This would 
determine car priority by a combination of known factors (commodity being moved, 
car type, etc. ) or by simply inputting a car priority code with its originating TCM 
or TCB message. 

The system will transmit to the destination station master a detailed consist con¬ 
taining all locomotive's identifications, etc., train number, origin and destination 
stations, followed by car information in the standing order of the cars in the train. 
The car information given is car number, status, sending and receiving stations, 
final destination, number of axles, gross weight, consignee, contract identification, 
and remarks. After all cars are listed, a train summary is given detailing length, 
weight, and axles. 

TCB is utilized each time a train is being made up. It creates a detailed consist for 
the TCM (Consist Maintenance) message to alter, and to reflect changes in the 
train as the train travels on its schedule. This transaction updates the Car Event, 
Train, and Station files, among others. 

TCM — Consist Maintenance 

This message is necessary when the actual cars and/or their standing order on the 
train are changed, due to: switching at a customer/industry siding between reporting 
stations stops (either pick ups or set off cars); cars (blocks) being set off or picked 
up at the reporting station; errors in the original consist (this includes missed 
connections that did not leave with the train from the prior yard); cars being bad 
ordered or bumped, etc. It is not necessary to reenter the entire consist, but 
merely to make the appropriate changes as required. TCM is used when a car is 
being added to or deleted from an existing consist; or when the consist contains 
errors. 

To identify the activity which has occurred, the following subcodes are required: 

® PIC — Unit is added (picked up) to the consist. 

« SET — Unit is deleted (set off) from the consist. 

© EXC — Correct exceptions noted between printed consist and actual 
standing train. 


3-4 



® BMP — Unit has been bumped from a train because of weight or 
length restrictions being violated, etc. 

• BAD - Unit has been removed from a train because it is 'bad ordered'. 

The information needed for the TCM message is as follows: 

Using PIC Subcode 
TCM 

Train Number 
PIC 

Number of preceding car on consist. 

Car number, status, commodity, origin station, destination station, final 
location, consignee, contract identification (if applicable), weight, and 
remarks. 

This line is repeated for each car in their standing order on the train. It 
is assumed that each car will follow the previous car entered. If not, line 3 
must be entered to indicate a new relative position on the train. Empty car 
information is entered as in TCB. 

Using SET Subcode 
TCM 

Train Number 
SET 

Unit number of car or first car of cut set off, followed by unit number of last 
car of cut set off. 

This line is repeated for each car or cut set off. 

Using EXC Subcode 
TCM 

Train Number 
EXC 
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Exception noted: 

ADD — Car on train but not on consist 
DEL — Car on consist but not on train 
REL — Relocate car on consist 
COR — Correct data on car 

If ADD is used, the following data must be entered. Number of preceding car on 
consist, car number, status, commodity, origin station, destination station, 
final location, consignee, contract identification (if applicable), weight and re¬ 
marks. (For connecting loaded cars, only car number needs to be input.) 

DEL requires only the car number referenced on the consist. This transaction 
is noted in the car event file. 

REL requires the number of the actual preceding car in the consist and the 
number of the car to be relocated. 

If the COR is used, the car number and all information relating to that car 
(see ADD) must be entered. If a car number is in error, then the preceding 
car number must be entered followed hy the correct car number (and any sub¬ 
sequent data being corrected). 

Using BMP Subcode 
TCM 

Train Number 
BMP 

Car Number, remarks. 

As with the Consist Build (TCB) message, additional edits are done to ensure that 
train limits and capacities are not exceeded. 


The Train, Car Event, and Status files are updated. 



An updated consist is generated for the next inbound yard. This updated consist 
now serves the same function as the original consist. A car being bumped will 
appear on a missed connection report and the system will note that the original 
schedule for the car is no longer scheduled; it will then require rescheduling by the 
system, or manual rescheduling if it cannot be automatically rescheduled. 

TDS — Dispatch Train 

As a train (with its consist reported or updated, ) departs from a station, that station 
reports this event via the TDS message. The message must contain the number of 
the train being dispatched and the actual departure time and date. If a station is 
reporting a dispatch for another station (computer terminal is not communicating or 
a station is not equipped with a computer terminal), the identity of the actual station 
the train is being dispatched from, must be given. If a station identification is not 
present, it is assumed that the dispatch is from the sending station. 

In addition to the normal edits, a check is made to ensure that the last event of 
this train was an arrival at this station, or that this is the origin station of this train. 

A dispatch message is then transmitted to the stations that this train will pass 
through, or stop at, notifying them that the train has left, together with any delay or 
other schedule adjustment information. 

The train event file is updated to provide proper data for inquiry and management 
reporting. 

An example of the TDS message is: 

TDS 

HAM (If a station is reporting for HAM) 

300157, 1645 - 30 

Train Actual time 

Number and date 

TAR — Arrive Train 

The TAR message should be transmitted as soon after a train arrives at a station as 
is practical. It must be sent before this train can be dispatched again. 
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This message is transmitted only to the central computer and serves to update the 
appropriate files. 

The message must contain the train number being arrived and the actual train arrival 
time and date. If a station is reporting an arrival for another station (computer 
terminal is out of order or a station is not equipped with a computer terminal), the 
identity of the actual station the train is being reported arrived at must be given. If 
a station identification is not present, it is assumed that the arrival is at the sending 
station. This information is used in train delay report generation, etc. 

If the preceding station has not dispatched this train, an area is reserved in the 
Train Event file for the dispatch information and a message is sent to the responsible 
station informing it of this required train data. 

An example of the TAR message is: 

TAR 

SKI (If a station is reporting for SKI) 

30157, 1740- 30 

TCR — Request Consist 

When a station desires a printout of a given train's consist, it uses the TCR message. 
The entry need only contain the train number, and train running date. This allows a 
yard master to plan train makeup with full knowledge of expected connections. 

The consist printed contains locomotive information for each locomotive (identification, 
type, capacity), train origin and destination stations, station last dispatched from, 
current location or stations, train length, train weight, and total number of axles. 

Each car is listed in standing order showing number, status, origin and destination 
stations, final destination, weight, and number of axles, customer contract informa¬ 
tion (if applicable), and remarks. A notification ordering a locomotive(s) off a train 
(as per the train's description) if the unit is to be removed, is added where 
appropriate. 

An example of the TCR request is: 

TCR 

30157 
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TCL — Train Cancel 


Should a previously scheduled train be canceled entirely or in part for one or more 
days, an appropriate message should be entered into the system. 

Entered are the train number, beginning date, ending date (if required), first station 
affected by cancel, last station affected by cancel, and remarks. The station entries 
are not required if the entire train is canceled. 

This message will update the corresponding files and cause a Cancelled Train 
message to be sent to the district centers and designated stations showing the stations 
and dates affected by this train cancellation. The message should not be confused 
with regular data base maintenance of the train schedule. 

TXT — Extra Train 

If an extra train or train section is scheduled, this message is transmitted by the 
appropriate regional center. This will update the various files to allow consists, 
dispatches, and arrivals to be generated, as well as initiating the system monitoring 
of this data. 

Data required is train number and type, effective dates, station stops, scheduled 
times, and locomotive information. This updates the Train Schedule Description 
file (Sched/Descr). 

A report containing this information is sent to affected stations, district 
and headquarters dispatching offices, etc. 

TDC — Train Description Change 

Should a change be required in train data, as entered in the Train Schedule Descrip¬ 
tion file, a TDC message is necessary. 

This is especially useful to railroads that closely schedule locomotives. Changes 
to locomotive assignments, length of train, capacity, and speed can be entered in 
this manner. In addition to the normal edits, locomotive assignments are validated 
to ensure that they are not contradictory. 

Files are updated and appropriate regional offices and stations are notified. 
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TDL — Train Delay 

When a train is delayed, it is important to keep the key operating departments 
informed. 

The TDL message is used to capture the key information relative to the delay, such 
as: train number, station, expected time of delay, and the reason for the delay. 

A train delay message showing expected length of delay is transmitted to the appropri 
ate regional centers and stations. 

The system uses this data to match against dispatches and schedules to summarize 
the reasons for delays, actual versus forecasted delays, and delays by district and 
train. 

TDR — Request Late Train Dispatch Summary 

When a dispatching office requires a summary of late dispatches, it can be obtained by 
the TDR request. 

Entered is the train number and date, for a simple request; if a specific leg of a 
train is to be queried, the from and to stations desired are identified. If an area is 
to be examined, the TDR message code is followed by AR and the district code(s) of 
the areas to be reviewed. 

An example of the TDR request is: 

TDR 

30157, 4 - 30, OKC, PAR 
TDR 

AR14, 4-30 

The report will indicate train number, station pair(s), date(s), delays, with reasons 
where available. 

TXS — Request Extra Train Summary 

The extra train or extra train section summary report is called by the TXS request. 
Dates or specific stations may be selected. 
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The report gives the cumulative extra train tonnage, total cars and weight (loaded 
and empty), total cars and weight picked up and set off, and the capacity utilized. 

This information is given for the cumulative period desired (either YTD to a defined 
date, or between two defined dates), and for a specified station set. 

TCS — Request Cancelled Train Summary 

The Cancelled Train Summary is called by this request. 

The report gives a monthly or a year-to-date summary of cancelled trains by station. 
The date, or dates, cancelled, and the reason cancelled (if known) is shown. This 
report is intended principally for head office traffic and dispatch management. 

TUL — Request for Weekly Summary of Train Capacity Utilization by Lane 

The capacity utilization summary by traffic lane is generated by the TUL request, by 
stating the train number and the originating and receiving station desired. (Entering 
ALL in originating station causes all stations to be printed for all traffic lanes. ) 

The report shows a weekly breakdown by originating and receiving station of axle 
capacity, braking capacity, total axles, total weight, axle count, and amount of 
capacity utilized. This is summarized for each day of the week. 

TUG — Request for Summary of Train Capacity Utilization by Leg 

This report is generated by the TUG request by entering the originating and receiving 
station and the dates desired. (Entering ALL in originating station causes all stations 
to be listed.) 

The report gives a summary (by originating and receiving station within dates) of 
capacity and amount utilized for each train leg of all trains. 

TSS — Request Switching Summary by Train 

When a location desires the switching summary of a particular train, it can be re¬ 
quested by this message. 

The desired date and train number is entered with the station identification (if other 
than the requesting terminal). 
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The report produced shows train number, date, station, and a summary of the total 
number of axles and weight of cars set off at that station; also a summary of the 
number of axles and weight that continued on the indicated train. 

TSD — Request Schedule Deviation Summary 

The Scheduled Deviation Summary is called by the TSD command. Train numbers 
and/or dates may be requested. 

The report summarizes by train number each delay, station delayed at, time delayed 
by arrivals and departures, and reasons for delays (if available). 

CAR TRANSACTIONS 

An alphabetical listing of car transactions and descriptions of these transactions are 
as follows: 


Transaction 

Function 

Page 

CBB 

Bad order car. 

3-13 

CBS 

Dispatch bad order car to maintenance shop. 

3-16 

CCR 

Bad ordered car returning or new car entering 
service. 

3-14 

ecu 

Request customer car utilization summary. 

3-18 

CFS 

Request foreign car summary. 

3-19 

CIA 

Car interchange arrival. 

3-13 

CID 

Car interchange departure. 

3-13 

CMP 

Dispatch empty car for pool storage. 

3-17 

CMS 

Return car in pool storage to service. 

3-17 

COF 

Request home cars off-line report. 

3-18 

COL 

Request on-line car summary by type. 

3-19 

CRC 

Reserve a car. 

3-16 

CRR 

Release reserved car. 

3-16 

CST 

Request car statistics report. 

3-18 

CUL 

Request car utilization report. 

3-18 
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CIA — Car Interchange Arrival 

Interchanging rolling stock between railroads is a frequent occurrence for many rail¬ 
roads. To assist operations management in their efforts to monitor and control cars 
affected by these movements, the CIA message is used. This message reports all 
home cars returning and foreign cars coming on the home line. 

The data entered consists of the station receiving the car (if different from the re¬ 
porting terminal), arrival time, and date. The following data regarding each car 
received is then entered: car number and type, status, commodity, destination, 
consignee, and gross weight. If the car is not a home car, the following additional 
data is required: empty weight, number of axles, braking coefficient, length, weight 
capacity, volume capacity, and any remarks which may be desired. 

Additional edits are performed to ensure that the car is not already reported on-line, 
that it is a correct car number (if home car), and has reasonable weight, length, and 
volume. 

CIA updates the Car file. Car Event file, and On/Off-line file. It is used each time 
a car or cut of cars comes on the home line, which have previously been reported 
off line; or for foreign cars entering the system. 

CID — Car Interchange Departure 

When reporting home or foreign cars going off-line, the CID message is provided. 

The data entered consists of the station code (if different from the reporting terminal), 
date, and time. Then the car number is repeated for each car in the cut. If car 
status, origin station, destination, consignee, or weight are required, these elements 
may be entered (in most cases the system will already have this data captured). 
Additional remarks may also be entered. 

CID updates the Car file. Car Event file, Status file, and the On/Off-line file. 

CBB — Bad Order Car 

This message is not used for cars already reported in a consist; bad ordered cars 
coming off a train are reported via a consist maintenance message. 
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If a car is discovered to be mechanically defective and unable to complete its 
currently scheduled movement(s) without maintenance, it must then be taken out 
of service and repaired. This message is used to report a car being ordered out 
of service due to mechanical defects. 

The data entered is: station code (if other than reporting station), car number, date 
and time, and a code describing the defect. The data base is updated concerning 
this car (Car Event file. Blocking Schedule file, future consists, and Maintenance 
file). It is reported on a missed connection report with a bad order code. The 
car is ordered by maintenance or operations personnel to a maintenance facility to 
be repaired, and appropriate move orders are generated. The car enters the 
maintenance reporting and monitoring functions in the on-line system. 

A car judged mechanically deficient, but still able to complete its current loaded 
move before repair, is reported with an entry code specifying this situation in the 
body of the message. This causes the Status file to be notified of this condition, and 
edit its next move to assure it is a maintenance movement, etc. 

CCR — Bad Order Car Returning or New Car Entering Service 

If a car is taken off-line for maintenance and is returning to service, or a new car is 
entering the rolling stock inventory, the CCR message causes the proper files to be 
updated. In addition, if cars change classification, are renumbered, or are perma¬ 
nently retired, this message is necessary. 

Four subcodes may be utilized by this message: 

RET — Bad order car returning to service 
NEW — New car entering service 
DEM — Car being retired or demolished 
CHG — Change car number or type code, etc. 

To use the RET subcode, the following entries are made (if applicable): 

© Car number 

© Date of next scheduled maintenance, and 

© Date of next scheduled brake maintenance. 
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To use the NEW subcode, the following entries are made: 

• Shop (location) identification 

® Car number 

® Type code 

® Date of scheduled maintenance 

® Date of scheduled brake maintenance 

• Empty weight 

• Weight capacity (axles) 

• Volume capacity 

• Length, etc. 

To use the DEM subcode, the following entries are made: 

• Shop (location) identification 

@ Car number 

• Effective date, and 

© Remarks 

To use the CHG subcode, the following entries are made (when applicable): 

• Shop (location) identification 

® Original car number 

« New car number 

0 New type 

• New weight capacity 

• New volume capacity, and 

0 Remarks 

The necessary files are updated making this unit available for inquiry responses, 
information reporting, and movement monitoring. 
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CBS — Dispatch Bad Order Car to Maintenance Shop 

When a car is located in a yard with a bad order (BAD) status, it must be dispatched 
to a maintenance shop for repair. The CBS message reports the car movement order 
needed for transporting the car to a designated shop via a train (or some other means). 

Information required on the entry is origin station (if different from the terminal 
sending the message), shop location, and each car number desired, together with 
designated train. 

Car number and location is checked together with valid station locations. 

This message is a car movement order similar to those described under the 
Maintenance and Car Distribution sections. It can be generated by yard operations, 
or maintenance personnel depending on the railroad's practice. The system updates 
the anticipated consist of the designated train and monitors the placement and move¬ 
ment of the car. Appropriate maintenance reporting is triggered by the message. 
Operations /Maintenance departments are responsible for ensuring that the car is 
fit for movement to a shop. The car is reported as bad ordered, moving to shop, in 
the appropriate consist. 

CRC — Reserve A Car 

If a car is to be reserved for a particular purpose, then this message is used. This 
causes a change in the Status code of the car, and any future movements of the car 
are checked to make certain that they are compatible with the new status code. 
(Examples of special purposes are: reserved for maintenance of vay supplies, and 
reserved for rail package traffic.) 

CRR — Release Reserved Cars 

Cars reserved for a specific purpose are released from that status by the CRR 
message. 

Car number is the only entry required in this message. Cars are assigned an 
empty (EMP) status after they are released and treated accordingly (see the Car 
Distribution section). 
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CMP — Dispatch Empty Car for Pool Storage 

The CMP message is a car movement order which assigns empty cars, located at 
various stations, to be pulled to a pool storage location, and stored for a period of 
time. 

The data entered is: the station where the car(s) is located (if different from the 
sending terminal), car number, pool location, and remarks. 

The station master is then informed that the car(s) should be put on a train to the 
pool location; the destination yard master is similarly informed. The data base is 
updated to reflect the changed status of such cars. 

An example of the CMP message is: 

CMP 

631715, MSP 
541756, MSP 
217631, FBO 

CMS — Return Car in Pool Storage to Service 

Cars in pool storage must be released from that status before they can be reported 
in a normal service status. 

The CMS message consists of the station code of the pool (if other than sending 
station), car number(s), destination station (if required), and remarks. 

The car is then ready to be entered on a consist for movement to a particular station 
or assigned to a customer. It would be handled via the car distribution function when 
that phase has been implemented. 

An example of the CMS message is: 

CMS 

631715, MAN 
541756 
217631, CGO 


3-17 



CCU — Request Customer Car Utilization Summary 

This message is used to trigger a summary of car utilization by the customer. It 
can be requested for one or more (up to all) customers. 

The report identifies, by customer, each car and type used, the origin and origina¬ 
tion date, and the destination and completion date of each movement. This shipper- 
oriented report is important to the marketing and traffic functions. 

CUL — Request Car Utilization Report 

To request a Car Utilization Report, the operator uses the CUL message. A given 
month or car type may be selected, or an entire year-to-date report on one or all 
types may be obtained. 

The report contains, for each type of car, the aggregate number of cars available 
during the period, number of cars used, average turnaround time, total weight 
hauled, average load weight, total mileage, and average length of haul per load. 

CST — Request Car Statistical Report 

The Car Statisical Report may be requested for a given car type (by entering the 
required car type code), for any or all car types. The month desired is requested. 
The report refers to home cars only. 

This report shows the average number of home cars available, average turnaround 
time, average weight per load, average number of movements empty and loaded, 
average time off-line, average time in maintenance or bad ordered, average time 
leased to a customer, average number of cars unused over five, ten, twenty, and 
thirty days. 

COF — Request Home Cars Off-Line Report 

The Off-line Car Report is called by the COF request. This message/report is in¬ 
tended for use by the Head Office or traffic management. Individual stations may 
request this type of information on a specific car(s), or car type through the INQ 
(inquiry) directive. 
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The report gives the time off-line, station where set off-line, originating station, 
returning station, and destination station when returned. These items are listed by 
car number for each off-line occurrence. 

CFS — Request Foreign Car Summary 

A report showing the foreign cars on-line on a requested date or within specified 
dates is generated upon input of this message. 

The report gives for all on-line foreign cars by owning railroad: the car number, 
type, date and location received, date and location returned (or put off-line). 

COL — Request On-Line Car Summary by Type 

To request a summary by car types within a given region, the COL request is used. 
The Head Office may request reports for any or all regions via this message. 

This report gives the total number of cars located in a region by type, and the overall 
total of all cars in that region. 

STATION/YARD TRANSACTIONS 



An alphabetical listing of station/yard transactions and descriptions 
actions are as follows: 

of these trans 


Transaction 

Function 

Page 

— 

SCD 

Request car detention report by station 

3-21 


SCI 

Request car type inventory by station or train 

3-21 

— 

SDR 

Request car detention report 

3-22 


SFC 

Request inbound freight summary for customer 

3-21 


SFO 

Request report of foreign cars on-line by owner 

3-21 


SFR 

Request foreign car report by station 

3-22 


SIW 

Request inbound workload report 

3-20 


SMC 

Request missed connection report 

3-20 


soc 

Request outbound car report 

3-22 


SSR 

Request station report 

3-20 
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SIW — Request Inbound Workload Report 

The Inbound Workload Report is requested by a station using the SIW message and 
entering the date or dates desired. 

This report shows by arrival time and train number, the following consist type 
information: 

• Car identification 

• Car type 

® Status 

• Final destination 

• Customer identification 

» Commodity 

• Net weight 

This information is given for all cars to be switched off at that station. This is 
generated from all trains scheduled in-bound for a specific date. 

SMC — Request Missed Connection Report 

A report listing missed train connections is available by station and date, or within 
dates. This is requested by the SMC message. 

The Missed Connection Report shows by date and station the origin and destination of 
the car, the train that the car arrived on (if any), the missed train, car number and 
type, and status (loaded, empty, etc.). Other factors such as weight, commodity, 
and contract identification (if applicable) may be added at the railroad's discretion. 

SSR — Request Station Report 

The station report may be requested by station name; or a district office or the head 
office may request a report for all stations or a group of stations. 

The report shows by station and month, the total time each car type has spent in the 
station. Foreign cars, by owner, as well as home cars are listed. 
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SFO — Request Report of Foreign Cars On-Line by Owner 

This report can be requested showing foreign cars on-line, by owning railroad,and 
length of time on-line. 

The report gives the movement history of all foreign cars on the home railroad's 
system. It shows by length of time and owner, each car number, major events 
concerning the car (stations assigned to and time assigned), total time on home line, 
and location and date the car departed from the system. This report permits the 
head office to review closely at any time, the path followed and work done by all 
foreign cars while they are on-line. 

SCD — Request Car Detention Report by Station 

This report is used to obtain a list of cars of a given type at a given station, the 
length of time the cars have been at that station, and any comments which may be 
available. 

In addition to the SCD message code, the equipment type code and station name (if 
other than sending terminal) should be included in the request. If ALL is substituted 
for equipment type, a summary of detention for all car types at the station is given. 
This is an important planning and yard measurement tool for both district and head 
office management as well as the yard master. 

SCI — Request Car Type Inventory by Station or Train 

A complete inventory of cars of a designated type at a station, or on a train, may be 
obtained by this message. Desired station name or train number must be included. 

The report gives by type the number and status of each car on a train or at a station. 
(If a train number is requested, the last reported location of that train is given. ) 
Overall totals are given for each car type. 

SFC — Request Inbound Freight Summary for Customers 

This report may be requested for all customers, or for a given customer, by including 
the customer identification with the SFC message code. 



Information on the report is by customer name and date. Included are: 

® arriving train number and date, 

® car number and type, 

• status, 

• originating station or location, 

• net weight, 

0 contract identification (if applicable), and 

m any appropriate comments. 

All known inbound traffic will be listed, whether it is on an actual or a future consist. 
SOC— Request Outbound Car Report 

This message requests a listing of all cars, waiting for outbound movement on 
trains, which are currently in a given station. 

The report shows the arrival train (if applicable), contract identification, car number 
and type, status, origin station, destination station, outbound train (if known), number 
of axles, gross weight, and comments. 

This report, together with inbound consists, and information available from the 
system showing cars allocated to expected train consists via the blocking/scheduling 
logic in the system, permits comprehensive planning by the yard master of switching 
instructions for train makeup, etc. 

SFR — Request Station Foreign Car Report 

An accumulated foreign car by station report is available through the SFR request. 

The report totals each type of car by number of days located at that station. It is 
given by car, by owner, with a grand total by owner. 

SDR — Request System Car Detention Report 

This report identifies cars by type and status which have been detained at each 
station 10 days, 11 to 15 days, 16 to 20 days, 21 to 30 days, and more than 30 days. 
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This report is triggered at the central site or headquarters by the SDR directive. 
This is a system wide report summarizing information which can be requested of a 
station/district level by the SCD request. It is used as an effective measurement of 
system efficiency, district and station work, etc. 

MAINTENANCE TRANSACTIONS 

An alphabetical listing of maintenance transactions and descriptions of these trans¬ 
actions are as follows: 




Transaction 

Function 

Page 



MAR 

Maintenance arrival notice 

3-23 



MCO 

Car maintenance order 

3-24 

— 


MCS 

Summary of car maintenance orders 

3-25 



MFR 

Forecasted car maintenance report 

3-25 

— 


MNC 

Noncompliance with MCO message 

3-25 



MNS 

Maintenance order noncompliance summary 

3-26 

— 


MSR 

Maintenance station recap 

3-26 



MTR 

Maintenance turnaround recap 

3-26 


MAR — Maintenance Arrival Notice 

The MAR message serves the function of reporting all cars (units) that arrive at a 
maintenance shop to the computer system. 

Data required is time and date when the car(s) arrived, and car number(s). The 
Car Event file and Status files are updated. Cars are automatically assigned a status 
of OOS (Out of Service) when in maintenance. 

An example of the MAR message is: 

MAR 

0300-0507 

322418 

691872 
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522731 


1630-0507 

678313 

678318 

MCO — Car Maintenance Order 

The maintenance shop or regional office may order cars (units) to be directed to a 
maintenance facility because of scheduled maintenance, or some other reason. 

The MCO message is concerned with directing stations to dispatch cars (units) to a 
specific maintenance shop as early as possible. 

Data in the message includes car number, and maintenance shop location to where the 
car is to be directed. 

An example of the MCO message is: 

MCO 

XYZ (maintenance shop) 

322418 

691872 

522731 

The computer will determine the current location or destination of the car, and direct 
a maintenance order regarding that car to the station where the car is, or will be, 
when it is unloaded. 

A message in the following form will be sent to the appropriate station: 

THE FOLLOWING UNITS AT YOUR STATION ARE SCHEDULED FOR 
MAINTENANCE. PLEASE DISPATCH TO XYZ AS SOON AS POSSIBLE. 

322418 

691872 
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or in the case of inbound traffic: 

THE FOLLOWING UNITS ARE INBOUND TO YOUR STATION. PLEASE 
DISPATCH TO XYZ AS SOON AS POSSIBLE. 

f 

CAR TRAIN NUMBER 

322418 30152 

522731 01630 

MNC — Noncompliance with MCO Message 

If a station is unable to dispatch a car to a maintenance shop as directed in the MCO 
message, it must use the MNC message to inform the maintenance area of this event, 
as well as when the car may be available for maintenance (if known). 

Data required for the MNC message is the maintenance location or sending location 
of the applicable MCO message, car number, expected availability date, the station 
where the car will be located when available (if known), and the reason for the delay. 

An example of the MNC message is: 

MNC 

XYZ 

322418, 05-15, KCM, LOADED TO KCM 
MFR — Forecasted Car Maintenance Report 

This report lists all cars (units) scheduled for maintenance in a given week. This 
report will assist the maintenance department in scheduling their workload and the 
car distribution department in ordering cars to maintenance shop locations, etc. 

The report shows car (unit) number and type, date due for maintenance, and type of 
maintenance scheduled (major overhaul, preventive, brake, etc. ), and last known status. 

MCS — Summary of Car Maintenance Orders 

This report is a summary of all Car Maintenance Orders (MCO) which were sent 
during the preceding week. Listed is the car (unit) number, station (location) that 
sent the message, the station the message was directed to, and the shop location. 
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MNS — Maintenance Order Noncompliance Summary 

This report is a weekly summary of all noncompliance with MCO messages (MNC) 
which were transmitted. 

Data on the report shows the station that sent the message, car (unit) number, ex¬ 
pected availability date (if available), the station where the car (unit) will be located 
when available (if known), plus the reason given for the noncompliance with the MCO 
message. 

MSR — Maintenance Status Recap 

This report lists units which have a BAD status at stations and an OOS status at 
shop locations. It is a cumulative report showing the length of time in that station 
and the status. It shows the maintenance status summary for the previous month. 

MTR — Maintenance Turnaround Recap 

This report lists the length of time a unit was in a maintenance shop (time unit was 
reported by MAR, though the time unit was reported back in service by CCR). 
Average time per equipment type, and type of maintenance performed, plus overall 
average turnaround time is calculated. 

This report is generated monthly, and on a year-to-date basis. Through this report, 
cars (units) requiring more than standard amounts of maintenance can be identified. 

CONTRACT TRANSACTIONS 

An alphabetical listing of contract transactions and descriptions of these trans¬ 
actions are as follows: 


Transaction 

Function 

Page 

KCM 

Contract maintenance. 

3-27 

KDR 

Contract deviation report. 

3-28 

Per Diem 


3-28 
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KCM — Contract Maintenance 

To add to, delete from, or modify transportation contracts which the railway may 
have with various customers, the KCM message is provided. 

The customer code and complete name must be included, with the alteration code for 
contract modifications. Following is the format for this message, describing the 
data which may be entered. 

KCM — Contract Maintenance message code 

CID, CNAME, M-CODE 

O-STA, D-STA, D-SID, CON-ID, CON-NAM, B-DATE, E-DATE, F-CODE, COMM, 
TR-NO 

CED = Customer identification number 
CNAME = Customer name 
M-CODE = Modification code 
ADD = Add record to file 

DEL = Delete record from file. (No additional input is necessary when 
deleting record) 

MOD = Modify the fields which contain data 
O-STA = Original station 
D-STA = Destination station 
D-SID = Destination siding 
CON-ID = Consignee number 
CON-NAM = Consignee name 
B-DATE = Beginning date of contract 
E-DATE = Ending date of contract 
F-CODE = Frequency code — two digit code 
COMM = Commodity code 
TR-NO = Train number (if applicable) 
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When performing a delete or modify operation, the customer identification number 
and name must match exactly with information which is currently on the file, or an 
error message is generated and the files are not updated. All fields entered are 
checked for validity. 

After the modify or add entry is made, the system returns the updated record for 
final verification by the operator. In the case of a delete, the entire record to be 
deleted is displayed to the operator before deletion. 

An example of the KCM message is: 

KCM— (Contract Maintenance message code) 

A65-16372, MEDINA SUPPLY INC., ADD 

MED,HAM, R63, 01052,HAMEL ELECTRIC CO., 03-05-75, 03-08-75 
WM, 1012, A30177 

KDR — Contract Deviation Report 

This report lists the deviations from contracted car movements. 

Information given is the date, sending customer, sending station, receiving customer, 
receiving station, car number, contracted or scheduled train, actual movement 
train, time delayed, and any remarks which may be available. 

This report is generated by request on a monthly or year-to-date basis. 

Per Diem 

Per diem is a daily charge for freight cars which have been hired by customers or 
interchanged with another railroad. 

Per diem is calculated by the system according to the rules and rates dictated by the 
particular railroad. This function may vary greatly between railroads, so it will be 
specifically tailored for a particular railroad. 

Data entry for per diem processing is achieved via the CIA, CID, CRC, and CRR 
messages and other manual data inputs describing loaded car movement. The 
calculations are done in an off-line batch environment. 
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Suggested reports generated are: 

® Daily Per Diem Transactions 

This report lists the daily car interchange and customer assignment 
transactions. It shows the railroad or customer interchanged with, 
point (station) of event, car number and type, and remarks. It is used 
for reference purposes. This will require off-line entry of customer 
car receipts. 

® Per Diem Preliminary Report 

This listing shows, by customer and railroad, the preliminary billing 
information, which should be checked for accuracy. 

® Per Diem Statements 

This is a printout of per diem statements to be sent to customers and 
interchange railroads. 

• Monthly Recap of Accounts 

This is a monthly recap, by railroad, of accrued and actual accounts 
receivable and accrued and actual accounts payable with totals. 

• Monthly Interchange Report 

For each railroad interchanged with, this report shows the breakdown, 
by car, of charges and other relevent information. 

DATA BASE UPDATE TRANSACTIONS 

An alphabetical listing of data base update transactions and descriptions of these 
transactions are as follows: 


rans action 

Function 

Page 

UCG 

Update car type and car group 

3-30 

UCT 

Cancels train 

3-30 

UIR 

Add new routes 

3-30 

UIT 

New train schedules 

3-30 

URO 

Update route data 

3-30 

USI 

Update siding data 

3-30 

UST 

Update station data 

3-30 

UTR 

Change train schedules 

3-30 
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URO — Updates the routes stored in the data base 

UIR — Inserts new routes in the data base 

UTR — Updates train schedules 

UIT — Inserts new train schedules in the data base 

UCT — Cancels train (permanently) 

UST — Updates station data stored in the data base. May also be used for 
inserting new station in the data base and to remove non-existing 
stations from the data base. 

USI — Updates, removes or inserts new data for sidings in the data base. 

UCG — Used for maintenance of the data base files containing information for 
car types and groups. 


SPECIAL DATA BASE UPDATE AND INQUIRY TRANSACTIONS 

The following files within the data base are updated infrequently but are vital to the 
operation of the railroad: 

• Station 

• ROST 

• Route 

© TRRO 

• Train No. 

e Sched/Descr 

• Siding 

• Car Type 

® Group Link 

• Group 


Transactions with transaction code UXXareused for updating of and inquiry into 
information kept in these files. The use of these transactions is restricted to a 
limited number of terminals. These terminals may either have update permission, 
inquiry permission, or both. 
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To perform the updating function, the transaction must be sent from a terminal 
with update permission, and the operator must also know a password which is given 
to each of the transactions. 


The following shows the general procedure for using these transactions: 


Step 

Performed By 

Terminal 1-0 

Comments 

it 

Operator 

UXX 

Transaction code. 

2 

System 

Password? 

Request password. 

3 tt 

Operator 

UPPW 

Gives valid password 

4 

System 

Update permission 
assigned 

The system acknowledges correct 
password 

5 

Operator 

TR, 602 

Operator inputs code which is 
necessary for locating correct data. 

6 § 

System 

Train No: 602 

Sch. Oslo, 1245, 
Gol, 1550, 

The system shows the data which is 
to be updated 



End schedules 

All data listed 

7 

Operator 

SCH. GOL, 1555 

Input given by operator; the input is 
keyword-oriented. 



END INPUT 

Signals end input data. 

8^ 

System 

Updated Data: 

Train No: 602 

Sch. Oslo, 1245 

Gol, 1555 

System shows how the inputted data 
will change the original data. 



End Schedules 

All data listed. 

9 

Operator 

UPDATE 

Operator executes the update. 

10 

System 

Updating finished 
at 1346 

System shows when updating took 
place. 


^ If the terminal is not allowed to use this transaction, an error message is 
printed. 


tt If the operator types NO instead of a valid password, he will automatically be 
given inquiry permission. Steps 7 and 8 will not be performed. 

§ The system always shows the data which may be updated. 

J When the operator has given END INPUT, the system will show how the inputted 
data will change the original data, but the actual updating will not take place until 
the operator has sent the message UPDATE to the system. The operator also has 
the option of doing other changes to the displayed data before the actual update 
takes place. 
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TRAFFIC AND SPECIAL TRANSACTIONS 

An alphabetical listing of traffic and special transactions and descriptions of these 
transactions are as follows: 


Transactions 

Function 

Page 

INQ 

Inquiry messages 

3-34 

XCF 

Comparative freight summary 

3-33 

XIO 

Inbound, outbound freight summary 

3-33 

XMT 

Request major customer traffic summary by route 

3-33 

XPM 

Practice mode 

3-33 

XRS 

Request train route summary 

3-32 

XTP 

Request traffic lane movement prediction 

3-32 


XRS — Request Train Route Summary 

This report lists, for a specific week's running of a train (number), the total number 
of axles, number of loaded cars of each type, number of empty cars of each type, 
net weight of each type, total weight of the train, net (freight) weight of the train, and 
total train length. 

Also, a weekly summary can be requested which shows the following totals for the 
week: Number of trains, number of loaded cars by type, number of empty cars by 
type, number of cars, net weight by type, and net weight of all trains. 

This data can be generated for one train for a week, all trains for a week, for 
traffic between two given stations on a weekly basis, or all stations, etc. 

These reports are useful in train schedule planning, weekly workload planning for 
a yard, etc. 

XTP — Request Traffic Lane Movement Prediction 

This message requests a listing showing for future trains: number of axles, and 
total weight expected to travel between two given stations. (This is derived from 
future consist information.) 
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Data used is all future-expected events in the Train File. This report is generated 
to show traffic between a selected pair of stations, which must be input with the 
XTP request. 

XMT — Request Major Customer Traffic Summary by Route 

This report is a monthly breakdown of tonnage carried for the railroad's major 
customers. It is requested by customer and by month. 

Listed by origin station are: destination stations, number of cars used that month, 
number of tons carried that month, and average tonnage per car. 

Overall totals are calculated for cars, tonnage, and average tonnage for the month. 
XCF— Comparative Freight Summary 

This report gives a yearly comparison of tonnage carried by route. The report 
shows year-to-date tonnage carried between points for the current year, and for 
the previous year. The difference, plus or minus, is given. These figures are 
given for regular trains and extra or special trains. This report is generated upon 
an authorized request. 

XIO — Monthly and Yearly Inbound Outbound Freight Summary 

This monthly and yearly report shows the number of loaded cars, empty cars, and 
tonnage which originated and terminated at a station. The report shows this data for 
each station in the railroad system. This report is also provided upon authorized 
request. 

XPM — Practice Mode Message 

The message type code XPM START can be entered to signify to the computer that 
all of the following messages (until PM STOP) from a terminal are for practice 
only, and will not update the files or be transmitted to the destination. The terminal 
will remain in practice mode until PM STOP is entered. All messages entered from 
the device while in practice mode are subject to the normal edits, and if an error 
is detected, the program will respond with the normal error message followed by 
PRACTICE MODE ENTRY NO FILE UPDATES OR TRANSMISSIONS CREATED. 


3-33 



This is extremely useful in training operations personnel at the beginning of system 
implementation and for training new operators, as well as for practice exercises of 
already trained personnel. 


INQ — Inquiry Messages 

In order to inquire about the various statuses of a given train(s) or car(s) or other 
unit(s), the INQ directive is available. This transaction will have a priority in 
Group 2, as described in Section 2. Following is a list of the available subcodes and 
a description of their functions: 


Subcode 
ST A 
HST 

POI 

ONL 

SAT 

LOC 


Information Requested 

Last reported status and location of this car, unit, or train. 

History of up to 14 calendar days of events that have been reported 
on this unit. Train events are available for four calendar days via 
this subcode. 

Location where a foreign unit was received, railroad received 
from (if applicable), date received, and type. 

Daily list of foreign units received on-line at the yard designated. 

Lists the anticipated arrival time of all inbound trains at that 
station, or anticipated arrival time of a given train. 

Lists all locomotives associated with a specific station; that 
is, scheduled to arrive, bad ordered, and on hand. 


The following format is used on all inquiry messages: 

INQ 

Subcode, train number, or car (unit) number, if necessary. 


LOCOMOTIVE TRANSACTION 

The locomotive transaction and description of this transaction are as follows: 
Transaction Function Page 

LFS Locomotive fleet status 3-34 


LFS — Locomotive Fleet Status 

One vital type of report which will be output describes locomotive fleet status. This 
report type is triggered by an LFS message which will generate a report on the past 
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week, or month, or YTD operating, etc,, history of the locomotives reported in a 
particular district, or of a particular fleet, or a system-wide summary of locomotive 
movement history. This report capability should prove a vital tool in assisting 
scheduling and dispatching personnel in scheduling and controlling the locomotive 
fleet. 

The road locomotive fleet, essential to the movement of trains, does not require a 
message type specific only to locomotives for the monitoring, scheduling, and control 
purposes which are the concern of this system. 

Locomotives can be prescheduled on trains by dispatchers updating the train descrip¬ 
tions in the Train File.. Actual running locomotives on trains are reported via consist 
build and consist maintain messages. 

"Dead heading" locomotives (locomotives running free between stations, and not 
associated with a train) can be reported via dispatch and arrival messages with a 
special subcode (LOC) followed by the locomotive(s) number(s); in the case of the 
dispatch message, the estimated time of arrival at the next designated station stop. 
This discipline allows files to be updated describing the locomotive fleet, and causes 
appropriate train dispatch offices, etc., to be notified of the train's actual move¬ 
ments. Naturally, a railroad's actual traffic control disciplines must be adhered to 
in determining when a dead heading locomotive can safely traverse the track — the 
system is not responsible for traffic control. 

Bad ordered locomotives are reported via the bad order message described in the 
car section (above). Again, the locomotive number is the vital link in the reporting 
discipline. 

Regular scheduling of locomotive maintenance is accomplished via the appropriate 
messages and reports described in the maintenance function (above). 

ADMINISTRATIVE MESSAGE SWITCHING 

The general purpose of this feature is the automatic switching of messages. This 
function operates in a selective or general broadcast mode; that is, messages can be 
directed to any specific terminal, or sent to all terminals. 
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The system holds all messages for a terminal when a problem arises with the line 
or the computer terminal device. When the problem is corrected, the message 
is printed; or it may be routed to an alternate device. This message switching 
capability has advantages over a telephone conversation in that both parties have 
written documentation of requests, and there is less chance of error. 

Administrative messages are all messages concerning administrative instructions, 
procedures, and reports; such as sales reports, empty mile reports, and all 
messages that do not require processing. This also includes customer service 
messages which do not request a reply. With administrative messages, no records 
or files are updated; they are merely transmitted to designated yard(s), etc. 

An example of an Administrative message is: 

ADM — Message code 

ABC — Station message is directed to 
text of message. 
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Section 4 

EXTENSION POSSIBILITIES 


This section describes future extension possibilities to the Rail-CARRIER system. 

CAR DISTRIBUTION 

The Rail-CARRIER car distribution capabilities could be augmented to further assist 
car dispatch management by the addition of the following transactions: 


Transaction 

Function 

Page 

DAD 

Additional car demand 

4-5 

DCH 

Change car distribution order from 

Headquarters to regional offices 

4-3 

DCM 

Change car distribution orders from 
regional office 

4-5 

DFM 

Foreign car move order 

4-3 

DFS 

Foreign car supply and demand 

4-2 

DMR 

Request summary of stations not reported 
car supply and demand 

4-5 

DRF 

Request summary of foreign car supply 
and demand 

4-6 

DRM 

Car distribution orders from regional 
offices to stations 

4-4 

DRS 

Request summary of car supply and demand 

4-6 

DSC 

Send cars 

4-3 

DSD 

Car supply and demand 

4-1 

DSF 

Change in move orders for foreign cars 

4-4 

DUF 

Unable to comply with foreign car orders 

4-3 

DUS 

Unable to comply with car orders 

4-5 


The following pages describe these transactions. 

DSD — Car Supply and Demand 

Once a day, all stations must report the available car supply at their respective 
stations, as well as car demands for the next 24 hours. This reporting must take 
place before a given time of the day. Stations must send this message even if 
they do not have a car supply or demand to report. The code for these messages 
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is DSD. The car demand and supply is reported in groups of car types; the number 
of cars in each group is reported. Data to be reported includes: 

® Supply 

Number of cars in each group, and comments 

• Demand 

Number of cars in each group, priority assigned to the 
demand, and comments 

Upon entry of this data, the system responds by assigning each reported demand 
and supply a unique reference number. If a station reports no car supply or demand, 
only the message code is sent. 

DFS — Foreign Car Supply and Demand 

The number of foreign cars at a station and the demand for foreign cars for the next 
24 hours are reported in the message DFS. This message is used only when nec¬ 
essary. Data on each available car is reported, such as: 

• Supply 

Car identification, type of car, owner, and comments 

• Demand 

Type of car needed, number of each type needed, capacity, 
owner, and comments 

The system assigns a reference number to each demand and supply which is reported. 

DHR — Car Distribution Order, Headquarters to Regional Offices 
The total home car demand and supply for each region (district) is reported by the 
system to Headquarters. A manual distribution will be done by Headquarters, and 
orders to move home cars from one region to another will be sent to the regional 
offices. Data sent by this message is: 

• region reference number, 

® region receiving the cars, 

® groups (generic type) of cars, 

e number of cars, and 

® comments. 

The system responds by assigning a unique reference number to each move order. 
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The messages are sent to the regional offices responsible for dispatching the cars 
and the regional offices receiving the cars. 

DCH — Change Car Distribution Order from Headquarters 
to Regional Offices 

The move orders from Headquarters to regional offices may be changed by Head¬ 
quarters by the message DCH. Data sent by this message is: 

• Headquarters reference number, 

• number of cars, and 

• comments. 

DSC — Send Cars 

When this message is sent from Headquarters, it informs the regional offices of no 
changes in the car distribution orders from Headquarters. The regional offices may 
then start distribution of the cars. The same message sent from a regional office 
informs the subordinate stations that the move orders are final and must be carried 
out as soon as possible. 

DFM — Foreign Car Move Order 

The foreign cars are distributed directly from Headquarters,and the message DFM is 
used to give the actual move orders directly to the stations. Data input in the 
message is: 

• demand reference number, 

• supply reference number(s), and 

• comments. 

The demand reference number corresponds to a reference number given by the system 
to a request for a foreign car. The supply reference number corresponds to a 
reference number given to the report of an available car at a station. The system 
uses the reference numbers for routing this message to the appropriate stations. 

The system assigns a reference number to the order. 

DUF — Unable to Comply with Foreign Car Order 

If a station is unable to comply with a foreign car move order, this is reported back 
to Headquarters. The message DUF is used for this purpose, and contains the 
following data: 
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© Reference number 


® Reason for not sending the car 
The reference number is assigned by the system to the move order. 

DSF — Change in Move Orders for Foreign Cars 

When a station reports that it is unable to comply with foreign car move orders. 
Headquarters may have to redistribute the foreign cars. This is done with the 
message DSF. Data input is: 

• Reference number 

Reference number assigned to the foreign car move order which is to 
be changed. 

• Demand reference number 

Foreign car demand reference number 

• Supply reference number (s) 

Foreign car supply reference number (s) 

• Comments 

This message is used any time that Headquarters wants to change a foreign car move • 
order. 

DRM — Car Distribution Orders from Regional Offices to Stations 

When the cars have been distributed from Headquarters between the regional offices, 
the regional offices will distribute the cars between the stations within their regions. 
The message DRS is used to inform the stations of the distribution orders as gen¬ 
erated by their regional office. Data which may be given is: 

• Demand reference number 

Reference number assigned to reported demand 

• Supply reference number(s) 

Reference number assigned to reported supply 

• Comments 

The reference numbers are used for routing the messages to appropriate stations 
and finding the destination of the cars. Each move order is assigned a reference 
number by the system; this number is used for later references to this move order. 
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DUS — Unable to Comply with Car Orders 

When a station is unable to comply with the car move orders, the regional offices are 
informed of this with the message DUS. Data input is: 

• reference number, 

• number of cars which may be sent, and 

• comments. 

Reference number refers to the move order. 

DCM — Change Car Distribution Orders from the Regional Office 

If the regional offices have to change a car move order, the message DCM is used. 

Data input is: 

• reference number, 

® demand reference number, 

• supply reference number, 

® number of cars, and 

• comments. 

The reference number points to the previous car move order cancelled by the system, 
and the system informs all the involved stations of the changes. 

DAD — Additional Car Demand 

If additional car demands occur after the regular car distribution has taken place, 
a station may inform the regional offices of this with the message DAD. The re¬ 
gional office may then use the message DRM to order stations to move cars to 
satisfy the demand. Data input is: 

• type or group of cars, 

• number of cars, and 

• comments. 

DMR — Request Summary of Stations Not Reporting Car Supply and Demand 

The regional offices may request a summary of the stations that have not reported 

car supply or demand with this message. 
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DRS — Request Summary of Car Supply and Demand 

This message is used by the regional office for requesting the report DLS which 
shows the car supply and demand within a region. The message may also be used 
by Headquarters for requesting the DRS report (car demand and supply of a region). 

DRF — Request Summary of Foreign Car Supply and Demand 

This input message is used by Headquarters for requesting the report DFS which 
gives the demand and supply of foreign cars. 


OUTPUT REPORTS 

New output reports provided by the Car Distribution resulting from the new input 
transactions are: 


Transaction 


Function 


DHS 

DRS 

DMR 

DRR 

DLS 

DAR 

DRM 

DMI 

DMC 

DCM 

DER 

DES 

DAD 

DDS 

DUS 

DFS 

DFM 

DFI 

DUF 

DFA 

DUC 


Headquarters summary of car supply and demand 

Summary of region car supply and demand 

Summary of station not reported car supply and demand 

Request car supply and demand report from a station 

Summary of car supply by station and type 

Acknowledge car supply/ demand report 

Car move orders to station from regional offices 

Inform stations that requested cars are being sent 

Changes in empty cars being sent 

Changes in the previous move orders 

Summary of cars which are required by a region 

Summary of empty cars which are to be sent from a district 

Report of additional car supply and demand 

Summary of the car distribution within a district 

Report of station unable to comply with car move orders 

Summary of foreign car supply and demand 

Foreign car move order to stations 

Informs stations that foreign cars are being sent to satisfy 
reported demand 

Station unable to comply with foreign car move order 

Acknowledge foreign car supply/demand message 

Report on stations unable to comply with foreign car 
move orders 
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Note that in some cases the input and output transaction codes are identical. The 
following paragraphs describe each of these reports in the order of their logical 
sequence. 

DAR — Acknowledge Car Supply and Demand Report 

When the car supplies and demands are reported by the station with the message DSD, 
this is acknowledged with the report DAR. This report lists the car supply and 
demand at the station and gives the reference number assigned by the system to each 
group of cars reported. 

DRR — Request Car Supply and Demand Report from a Station 

If a station fails to report car supply and demand within a predefined time of the day, 
the system automatically requests this by the DRR report. 

DMR - Summary of Stations Not Reporting Car Supply and Demand 
At a predefined time of the day, the system produces this report to inform the re¬ 
gional offices of stations that have not yet reported car supply and demand. The re¬ 
port may also be requested at any time by the regional offices with the message DMR. 
Only the stations subordinate to the regional office receiving the report are listed. 

The report contains the identification of the stations not reported. 

DLS - Summary of Car Supply and Demand by Station and Type 
This report is produced for each region automatically at a predefined time of the 
day, or when all the stations within a region have reported car supply and demand. 
The report may also be requested by the regional offices with the message DRS. 

The report shows the car demand and supply for each group of cars at all stations. 

It also shows the reference numbers assigned by the system to each of the reported 
car demands and supplies. The report gives a summary of total car demand and 
supply within the region. 

DRS - Summary of Region Car Supply and Demand 

Headquarters automatically receives this daily report which shows the number of 
cars in each group available in, or demanded by, a region. The report also shows 
the reference number assigned to each region's car demand and supply. The report 
may also be requested by Headquarters, and will then show the current car demand 
and supply of the region. 
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DER - Summary of Cars Received by a Region 

This summary is received by a regional office when Headquarters has ordered other 
regions to send cars to this region to satisfy reported car demand. The summary 
contains: 

@ reference number to the reported demand, 

• groups of cars, 

® number in each group, 

@ sending region, and 

@ comments. 

DES — Summary of Empty Cars Sent from a Region 

When Headquarters has distributed the reported available cars between the regions, 
this summary is sent to the regional offices which are to transfer cars to another 
region. The summary contains: 

® reference number of move order, 

• reference number of reported car supply, 

® groups of cars, 

® number in each group, 

• receiving regions, and 

• comments. 

DMC — Change in Empty Cars Being Sent 

This output may be initiated by Headquarters to the regional offices or by the re¬ 
gional offices to the stations. It informs the receiver that cars requested will not 
be sent as reported in the DER summary; the report will be sent to the regional 
offices or the stations which are involved in the changes. The report shows the 
changes and contains: 

• reference number of reported demand, 

® group, 

® number in group, 

@ sender, and 

® comments. 
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DCM — Changes in the Previous Move Orders 

This report is sent to regional offices or stations when the car move orders are 
changed by Headquarters or regional offices. The reports override previous move 
orders and contain: 

• previous move order reference number, 

• group, 

@ number of cars in each group, 

@ receiver, and 
@ comments. 

DRM - Car Move Orders to Stations from Regional Offices 

The stations are ordered to send cars by the report DRM. The report contains: 

• move order reference number, 

• car supply reference number, 

9 group, 

@ number of cars in each group, 

• receiving station, and 
e comments. 

DMI - Inform Stations that Requested Cars are Being Sent 

The stations are informed that cars are being sent to them to satisfy a reported car 
demand by the report DMI. The report contains: 

® demand reference number, 

• name of sending stations, 

© number of cars sent from each station, and 

• comments. 

DUS - Report That a Station is Unable to Comply with Car Move Orders 
If a station is unable to comply with a car move order, the message DUS is sent 
from the station. This produces the report DUS at the regional office. The report 
contains: 

® move order reference number, 

© sending station, 

© receiving station, 

® number of cars ordered, 
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© number of cars to be sent, 

• group of cars, and 
@ comments. 

DDS — Summary of the Car Distribution within a Region 

When the regional offices have finished the car distribution within a district, the 
report DDS is produced. The report shows: 

@ each move order, 

® which station is sending the cars, 

• which station is receiving the cars, etc. 

It also gives a summary of the total number of cars that have been sent and received, 
and data describing cars received from other regions. 

DAR — Report on Additional Car Demand 

When a station reports additional car demand by the message DAD, this report is 
produced at the corresponding regional office. The report contains: 

• reference number, 

® station, 

® group of cars, 

• number of cars in group, 

• priority, and 
® comments. 

DFS - Summary of Foreign Car Supply and Demand 
s This report may be requested by the input message DRF by Headquarters, but it 
will also be produced automatically at predefined times. The report gives a summary 
to Headquarters of the foreign car supply and demand of the stations. Data to be 
reported is: 

© Region, station 

• Supply 

Reference number, type, owner, capacity, quantity, and comments. 

® Demand 

Reference number, type, owner, capacity, quantity, priority, and comments. 
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DFA — Acknowledge Foreign Car Supply/Demand Message 

When a station reports foreign car supply and demand by the message DFS, the sys¬ 
tem acknowledges this with the output DFA. This output echoes the data input by 
DFS and gives the reference number assigned to reported foreign car supply and 
demand. 

DFM — Foreign Car Move Orders to Stations 

Headquarters orders a station to send foreign cars by this message. Data output to 
the stations is: 

@ supply reference number, 

• car number, 

@ receiving station, and 
® comments. 

DFI - Inform Station that Foreign Cars are Being Sent to Satisfy 
Reported Demand 

When a station has been ordered by Headquarters to send cars to another station, 
the receiving station is informed of this with the report DFI. Data output is: 

® demand reference number, 

® car number, 

® sending station, and 

• comments. 

DUF — Station Unable to Comply with Foreign Car Move Order 

If a station is unable to comply with a foreign car move order, the station sends the 
message DUF to Headquarters. This causes report DUF to be given to the station 
expecting the car. The report contains: 

@ demand reference number, and 
® comments. 

DUC — Report on Stations Unable to Comply with Foreign 
Car Move Orders 

When a station reports that it is unable to comply with a foreign car move order, the 
report DUC is produced at Headquarters. The report gives the name of the stations 
reported, and repeats information about the needed cars. 
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YARD REPORTS 


This possible refinement of the on-line systems is intended to widen the spectrum of 
railroad operations activities being reported- In the previous sections of this docu¬ 
ment, the system was concerned with loaded cars being first reported when they 
were entered onto their first train's consist, and then being reported on each sub¬ 
sequent consist (together with train arrival and dispatch information) until they reach 
their destination train or yard. Empty cars are reported via the car distribution 
function as they are monitored and controlled from the origination yard to a desti¬ 
nation yard (or to storage), as are maintenance-due cars. 

Detailed information on delivery and pickup switching operations with industry is 
lacking from this earlier information,as is the detailed information describing car 
loading/unloading activities in a yard, and reloading activities (unloading followed 
by loading wih a different consignment). This information may be desired or nec¬ 
essary for way-billhg requirements, closer demurrage and per diem accounting, and 
closer planning and monitoring of various yard work (especially industrial switching). 

To assist in these areas, the data described below would be reported to a yard re¬ 
porting function expanded over that described earlier. This would be reported via a 
YDR message, and the particular event(s) being reported would be identified via 
various subcodes. This reporting should also be designed so as to encompass a 
particular railroad's way-billing requirements (that is, all way-billing data required 
should be captured at this phase). These yard reports should be input regularly 
throughout the day to report the flow of cars to and from industry,in a timely fashion. 

The subcodes and the data to be reported by these subcodes as described below. 

The initial subcode LOB for cars pulled from industry and waiting to move would 
input (any) required way-bill data and would also cause the system to completely 
assign a movement route, blocking pattern, and a set of assigned train schedules 
for each LOB car (providing the railroad desired this feature and its operations 
allowed it). This would obviate the initial train movement assignment by the yard 
master as practiced in the earlier implementation; however, total automation of this 
function should be carefully approached by the operating department. 



Subcodes for yard reporting are: 

1. LOB — Loaded Outbound (pulled from industry and waiting for train) 


Car name and number 
Destination 
Customer name 
Contract number 
Commodity code 
Weight 

Time and date loaded 
Revenue, consignee 

2. WOB — Working Outbound (Spotted in yard for loading) 

Car name and number 
Destination 
Commodity code 
Weight 

Time and date started 
Projected LOB date 
Consignee 

3. SCL — Spotted at Customer Siding for Loading 

(This subcode is used for reporting actual customer 
delivery or spotting information) 

Car name and number 

Industry name and address (or code) 

Time and date spotted 
Pay code 

Projected LOB date 
Commodity code (if known) 

4. SCR — Spotted at Customer Siding for Reloading 

(Car is unloaded by customer and then 
reloaded immediately) 

Car name and number 

Industry name and address (or code) 

Time and date spotted 
Pay code 

Projected LOB date 
Commodity code (if known) 

5. SCU — Spotted at Customer Siding for Unloading 

Car name and number 

Industry name and address (or code) 

Time and date spotted 
Pay code 
Commodity code 
Projected EMP date 
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6. RCP — Released by Customer for Pulling 


Car name and number 
Loaded or empty 
Time and date released 
Projected pull date/time 
Destination (if loaded) 

Weight (if loaded) 

Commodity code (if loaded) 

Again the set of subcodes implemented should correspond with the practices of a 
particular railroad, which may mean that more or less subcodes would be required. 
Information reported for a particular subcode would also possibly vary for a particu¬ 
lar railroad. For example, the RCP subcode is possibly considered implementable 
principally for railroads with complex industrial switching problems, resulting in 
switching planning problems; and the data reported would be considerably less than 
that shown if the subcode is used only for gathering switching planning and monitoring 
information. 

Summary reports describing industrial switching (pulling and spotting) activity and 
detailed and highly accurate demurrage accounting are some of the types of reports 
which could be generated by this system. 

A detailed reporting, monitoring, and planning subsystem for use with all industrial 
switching activity could be visualized as an extension to the yard reporting area. 

This would include scheduling and generating work orders for all non main-line car 
activity such as: spotting cars to industry from a yard, pulling from industry to a 
yard, spotting and pulling activities concerning cars in storage or hold track areas 
(both loaded and empty cars), switching cars between industrial locations or within 
industrial locations, interchange switching, and some yard-to-yard switching. This 
is a more advanced yard control concept and must be carefully examined for opera¬ 
tional feasibility in a railroad before it should be implemented. 

CUSTOMER SERVICE INQUIRY 

A customer service inquiry is a customer service message which asks for a reply. 
The message type code for a customer service inquiry is ACS.^ This message type 
code is used when asking for delivery information or any type of tracing question to 
a yard or othe r location that requires a reply. 

t This message type should not be confused with the inquiry capability (INQ inquiry 
message) all terminal-equipped locations have to determine the last reported status 
of all rolling stock. 
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The use of abbreviations is recommended as they can speed handling and, if properly 
used, can save a considerable amount of time in keying in a request and in transmis¬ 
sion time on the lines. 

If the message is a customer service message that does not need a reply, the mes¬ 
sage should be coded as an ADM, administrative message. 

In addition to transmitting the customer service inquiry message to the terminals 
being addressed, the only processing that will be done with customer service in¬ 
quiries is that they will be assigned a message number by the computer and stored in 
a customer service file until they are answered. 

The following evening, the Customer Service Inquiry file is matched to the Customer 
Service Reply file, and the unanswered ACS messages are retransmitted to the nec¬ 
essary stations. This is done daily. After a message is three days old, it is dropped 
from the files and Customer Service Control is notified. 

The program does not accept a message addressed to a nonreporting terminal. Such 
messages should be addressed to the nearest station with a computer terminal and 
forwarded. 

Surveys are run on a daily, weekly, and monthly basis to determine if any terminals 
are not answering the messages, addressed to them. 

On all messages, the terminal or terminals to which the message should be distri¬ 
buted must be specified by the operator in the form of the alphabetic terminal code of 
the terminal or terminals being addressed. 

The following information is needed to send a customer service inquiry message: 

® ACS (message type code of a customer service inquiry message) 

® Alphabetic terminal code of the destination station for each station to 
receive this message 

• Name of the person to receive the message 
® The message 

The immediate response is the date and time stamp. 
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CUSTOMER SERVICE REPLY 


A customer service reply is actually the reply to a corresponding customer service 
inquiry. The message type code for a customer service reply is ACR. As stated in 
the customer service inquiry explanation, the computer assigns a number to all 
ACS messages. This number is transmitted to the destination station together with 
that message. When a reply is made to this customer service message, it should be 
coded ACR and have the number of the corresponding ACS message on it. In this 
manner, the customer service inquiries are matched to determine which ones have 
not been answered. 

The following information is needed in a customer service reply message: 

• ACR (message type code of a customer service reply message) 

® Alphabetic terminal code of the destination station for each station to 
receive the message 

• The number of the customer service inquiry message that this 
message is answering 

• The reply message 

The date and time stamp is returned upon message entry. 

DEMURRAGE REPORTS 

Demurrage is a charge for detention of freight cars held by shippers or consignees 
beyond a prescribed free time, and is assessed for the prupose of expediting the 
release of freight cars. 

As a car is moved to a customer's siding, a Yard Report entry is made entering a 
car status of SCL (Spotted at Customer's Siding for Loading), SCU (Unloading), or 
SCR (Reloading). Charges are normally calculated on the car after 48 hours, not 
counting weekends and holidays, depending on rates charged per type of car. These 
rates are calculated until an RCP (Released by Customer for Pulling) message is 
received. 

Special consideration is given for any of the following reasons: 

® Commodity is being exported through the port where the car is held, 
requiring the car to be held for customs. 

® Extraordinary occurrences, such as weather, wreck, cancelled train, etc. 

® Freight is being held for inspection. 
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Other free-time allowances vary according to reason for placement and commodity. 

Charges are calculated and statements printed. Also, reports are generated showing 
each customer by station and a recap of accounts receivable. 

Because demmurage is governed by local tariffs and regulations, this system must 
be localized for a particular railroad. Many exceptions do exist to these regulations; 
therefore, the ability to handle exceptions manually is provided. 

The following demurrage reports are created by the system: 

• Daily Demurrage Transactions 

This report lists demurrage transactions for the day by station. It gives 
car name and number, equipment type code, industry name (or code), date 
set off, and remarks. 

® Preliminary Demurrage Billing Lists 

This report lists, by industry, the billing information to be checked for 
accuracy. 

• Demurrage Record Update Listing 

This report shows a record of deletions and changes made to the preliminary 
billing statement list. 

® Demurrage Statement 

This is a printout of demurrage charges. 

• Monthly Recap of Demurrage Accounts by Industry 

This is a monthly recap, by industry, of accrued and actual accounts re¬ 
ceivable for demurrage. 

® Monthly Demurrage Report 

For each industry accruing demurrage charges, this report shows the break¬ 
down, by car, of the charges and other relevant information. 
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Section 5 

IMPLEMENTATION 


Because of the complexity of the Rail-CARRIER system and the impact the imple¬ 
mentation of this system could have on the operational procedures of a railroad, 
the Rail-CARRIER system will not be installed in one step. The installation may be 
divided into five phases. This will enable personnel using the system, to become 
accustomed to the reporting procedures and the messages and reports produced by 
the system. 

The implementation plan calls for implementation of a new phase each six months. 

It is assumed that the hardware and general software have been installed and accepted 
before implementation of the Rail-CARRIER system begins. 

PHASE I 

This phase is primarily for testing and training. The main purpose of this phase is 
to familiarize personnel who are going to use the system,with the operational pro¬ 
cedures of the terminals and the reporting procedures necessary to ensure successful 
operation of the system. Only basic transactions for reporting car and train move¬ 
ments will be implemented, and only reports which are vital for the movements of 
cars and trains will be produced. 

The Phase 1 system will be run in parallel with the manual system; train and car 
movement will not depend on the operation of the Rail-CARRIER system. This 
phase will also be used for inputting data for all cars on the user's railroad. During 
the last part of Phase 1, the Rail-CARRIER system will gradually become the pri¬ 
mary system for monitoring the control of the traffic on the railroad network, with 
the manual system used as a backup system. Transactions implemented during this 
phase are: CCR, INQ, TAR, TCB, TCL, TCM, TCR, TDC, TDL, TDS, TXT, UCG, 
all UXX transactions, and XPM. 

PHASE 2 

In this phase, the system tested during Phase 1 will be put into full production. 
Reports necessary for localizing cars and for producing statistics oh trains and 
routes will be added. Implementation of maintenance scheduling functions will also be 
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started during this phase. New transactions which become available during this 
phase are: CBB, CIA, CID, CMP, CMS, CRC, CRR, SCD, SCI, SFO, SFR, SIW, 
SOW, and TXS. 

PHASE 3 

Mainte nan ce scheduling based on the elapsed time since the last overhaul and on 
reported defects will be available through the Rail-CARRIER system. New trans¬ 
actions for reporting the status and localization of the railroad's rolling stock will 
be made available, and the system will produce reports which show the utilization 
of the railroad's rolling stock. 

The system will also produce reports which show cars and locomotives due for 
maintenance in a given time period. Customer contract maintenance is also 
available during this phase. New transactions added are: CBS, CCU, CFS, COF, 
COL, KCM, KDR, all MXX transactions, SFC, TCS, TDR, TSS and XIO. 

Testing of the car distribution system will start in the latter part of this phase. 

PHASE 4 

The car distribution system will become operational in this phase. All necessary 
transactions and reports for this phase will be made available (all DXX transactions 
are added during this phase). 

PHASE 5 

This phase will add traffic studies and yard reporting. Transactions and reports 
tailored for the railroad's particular need will also be added during this phase. The 
remainder of the Rail-CARRIER transactions will also be added during this phase. 
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Section 6 

MESSAGE INDEX 


This section contains an alphabetical listing of transactions and also a listing of 
transactions by priority. 

Transaction Function Page 


CBB 

— 

Bad order car 

3-13 

CBS 

— 

Dispatch bad order car to maintenance shop 

3-16 

CCR 

— 

Bad ordered car returning or new car entering 
service 

3-14 

ecu 

— 

Request customer car utilization summary 

3-18 

CFS 

- 

Request foreign car summary 

3-19 

CIA 

— 

Car interchange arrival 

3-13 

CID 

— 

Car interchange departure 

3-13 

CMP 

— 

Dispatch empty car for pool storage 

3-17 

CMS 

- 

Return car in pool storage to service 

3-17 

COF 

— 

Request home cars off-line report 

3-18 

COL 

— 

Request on-line car summary by type 

3-19 

CRC 

— 

Reserve a car 

3-16 

CRR 

— 

Release reserved car 

3-16 

CST 

— 

Request car statistics report 

3-18 

CUL 

— 

Request car utilization report 

3-18 

DAD 

_ 

Additional car demand 

4-5 

DCH 

— 

Change car distribution order from Headquarters 
to regional offices 

4-3 

DCM 

— 

Change car distribution orders from regional office 

4-5 

DFM 

- 

Foreign car move order 

4-3 

DFS 

— 

Foreign car supply and demand 

4-2 

DMR 

— 

Request summary of stations not reported 
car supply and demand 

4-5 

DRF 

— 

Request summary of foreign car supply and demand 

4-6 

DRM 

- 

Car distribution orders from regional offices 
to stations 

4-4 
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Transaction 

Function 

Page 

DRS 

— 

Request summary of car supply and demand 

4-6 

DSC 

— 

Send cars 

4-3 

DSD 

— 

Car supply and demand 

4-1 

DSF 

— 

Change in move orders for foreign cars 

4-4 

DUF 

— 

Unable to comply with foreign car orders 

4-3 

DUS 

- 

Unable to comply with car orders 

4-5 

INQ 

- 

Inquiry messages 

3-34 

KCM 

_ 

Contract maintenance 

3-27 

KDR 

— 

Contract deviation report 

3-28 

LFS 

— 

Locomotive fleet status 

3-34 

MAR 


Maintenance arrival notice 

3-23 

MCO 

— 

Car maintenance order 

3-24 

MCS 

— 

Summary of car maintenance orders 

3-25 

MFR 

— 

Forecast car maintenance report 

3-25 

MNC 

— 

Non-compliance with MCO message 

3-25 

MNS 

— 

Maintenance order non-compliance summary 

3-26 

MSR 

— 

Maintenance status recap 

3-26 

MTR 

— 

Maintenance turnaround recap 

3-26 

SCD 

_ 

Request car detention report by station 

3-21 

SCI 

— 

Request car type inventory by station or train 

3-21 

SDR 

— 

Request car detention report 

3-22 

SFC 

— 

Request inbound freight summary for customer 

3-21 

SFO 

— 

Request report of foreign cars on-line by owner 

3-21 

SFR 

— 

Request foreign car report by station 

3-22 

SIW 

— 

Request inbound workload report 

3-20 

SMC 

— 

Request missed connection report 

3-20 

soc 

— 

Request outbound car report 

3-22 

SSR 

— 

Request station report 

3-20 
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Transaction 

Function 

Page 

TAR 

— 

Arrive train 

3-7 

TCB 

— 

Consist build 

3-3 

TCL 

— 

Train cancel 

3-9 

TCM 

— 

Consist maintenance 

3-4 

TCR 

- 

Request consist 

3-8 

TCS 

- 

Request cancelled train summary 

3-11 

TDC 

- 

Train description change 

3-9 

TDL 

- 

Train delay 

3-10 

TDR 

- 

Request late train dispatch summary 

3-10 

TDS 

— 

Dispatch train 

3-7 

TSD 

— 

Request schedule deviation summary 

3-12 

TSS 

— 

Request switching summary by train 

3-11 

TUG 

— 

Request summary of train capacity utilization 
by leg 

3-11 

TUL 

— 

Request weekly summary of train capacity 
utilization by lane 

3-10 

TXS 

— 

Request extra train summary 

3-10 

TXT 

— 

Extra train 

3-9 

UCG 

_ 

Update car type and car group 

3-30 

UCT 

- 

Cancels train 

3-30 

UIR 

— 

Add new routes 

3-30 

UIT 

— 

New train schedules 

3-30 

URO 

- 

Update route data 

3-30 

USI 

- 

Update siding data 

3-30 

UST 

— 

Update station data 

3-30 

UTR 

— 

Change train schedules 

3-30 

XCF 

— 

Comparative freight summary 

3-33 

XIO 

— 

Inbound, outbound freight summary 

3-33 

XMT 

— 

Request major customer traffic summary 
by route 

3-33 

XPM 

- 

Practice mode 

3-33 

XRS 

— 

Request train route summary 

3-32 

XTP 

— 

Request traffic lane movement prediction 

3-32 
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TRANSACTIONS GROUPED BY PRIORITY 


Group 1 


Transaction 

Function 

Page 

CBS 

— 

Dispatch bad order car to maintenance shop 

3-16 

CMP 

— 

Dispatch empty car for pool storage 

3-17 

DCH 

— 

Change car distribution order from Headquarters 
to regional offices 

4-3 

DCM 

— 

Change car distribution orders from 
regional office 

4-5 

DFM 

— 

Foreign car move order 

4-3 

DFS 

— 

Foreign car supply and demand 

4-2 

DRM 

— 

Car distribution orders from regional 
offices to stations 

4-4 

DSC 

— 

Send cars 

4-3 

DSD 

- 

Car supply and demand 

4-1 

DSF 

— 

Change in move orders for foreign cars 

4-4 

DUF 

— 

Unable to comply with foreign car orders 

4-3 

DUS 

— 

Unable to comply with car orders 

4-5 

TAR 

— 

Arrive train 

3-7 

TCB 

— 

Consist build 

3-3 

TCL 

— 

Train cancel 

3-9 

TCM 

— 

Consist maintenance 

3-4 

TDL 

— 

Train delay 

3-10 

TDS 

— 

Dispatch train 

3-7 

XPM 

— 

Practice mode 

3-33 

Group 2 

CBB 

- 

Bad order car 

3-13 

CIA 

— 

Car interchange arrival 

3-13 

CID 

— 

Car interchange departure 

3-13 

CCR 

— 

Bad ordered car returning or new car 
entering service 

3-14 

CMS 

— 

Return car in pool storage to service 

3-17 

CRC 

— 

Reserve a car 

3-16 

CRR 

— 

Release reserved car 

3-16 
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Transaction 

Function 

Page 

DAD 

— 

Additional car demand 

4-5 

DMR 

— 

Request summary of stations not reported 
car supply and demand 

4-5 

DRF 

— 

Request summary of foreign car supply 
and demand 

4-6 

DRS 

- 

Request summary of car supply and demand 

4-6 

INQ 

- 

Inquiry messages 

3-34 

MAR 

— 

Maintenance arrival notice 

3-23 

MCO 

— 

Car maintenance order 

3-24 

MNC 

— 

Non-compliance with MCO message 

3-25 

SCD 

— 

Request car detention report by station 

3-21 

SCI 

— 

Request car type inventory by station or train 

3-21 

SIW 

- 

Request inbound workload report 

3-20 

soc 

- 

Request outbound car report 

3-20 

TCR 

- 

Request consist 

3-8 

TDC 

— 

Train description change 

3-9 

TXT 

— 

Extra train 

3-9 

UCG 

— 

Update car type and car group 

3-30 

UCT 

- 

Cancels train 

3-30 

UIR 

- 

Add new routes 

3-30 

UIT 

— 

New train schedules 

3-30 

URO 

— 

Update route data 

3-30 

USI 

— 

Update siding data 

3-30 

UST 

- 

Update station data 

3-30 

UTR 

- 

Change train schedules 

3-30 

Group 3 

CFS 

— 

Request foreign car summary 

3-19 

COL 

— 

Request on-line car summary by type 

3-19 

KCM 

— 

Contract maintenance 

3-27 

MCS 

- 

Summary of car maintenance orders 

3-25 

MFR 

— 

Forecast car maintenance report 

3-25 

MNS 

- 

Maintenance order non-compliance summary 

3-26 

MSR 

- 

Maintenance status recap 

3-26 

MTR 

— 

Maintenance turnaround recap 

3-26 
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Transaction 

Function 

Page 

SFC 

- 

Request inbound freight summary 
for customer 

3-21 

SFO 

— 

Request report of foreign cars on-line 
by owner 

3-21 

SFR 

- 

Request foreign car report by station 

3-22 

TDR 

- 

Request late train dispatch summary 

3-10 

XRS 

- 

Request train route summary 

3-32 

XTP 

- 

Request traffic lane movement prediction 

3-32 

TUL 

— 

Request weekly summary of train capacity 
utilization by lane 

3-11 

TXS 

— 

Request extra train summary 

3-10 

Group 4 

ecu 

— 

Request customer car utilization summary 

3-18 

COF 

— 

Request home cars off-line report 

3-18 

CST 

— 

Request car statistics report 

3-18 

CUL 

- 

Request car utilization report 

3-18 

KDR 

— 

Contract deviation report 

3-18 

LFS 

- 

Locomotive fleet status 

3-34 

SDR 

— 

Request car detention report 

3-22 

SMC 

— 

Request missed connection report 

3-21 

SSR 

- 

Request station report 

3-20 

TCS 

— 

Request cancelled train summary 

3-11 

TSD 

— 

Request schedule deviation summary 

3-12 

TSS 

— 

Request switching summary by train 

3-11 

TUG 

— 

Request summary of train capacity utilization by leg 

3-11 

XCF 

— 

Comparative freight summary 

3-33 

XIO 

- 

Inbound, outbound freight summary 

3-33 

XMT 

— 

Request major customer traffic summary 
by route 

3-33 
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